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ABSTRACT 


The Naval Postgraduate School is developing an vertical take-off and landing (VTOL) unmanned air 
vehicle (UAV) tluit can tnmsition to horizontal flight, once airborne, in order to take advantage of the 
improvements in speed, range, tind loiter time that horizontal, fixed-wing flight provides. This research 
investigates the design requirements of the central controlling device for that UAV, including the specific 
problems of defining the necesstuy htu-dwtu-e components and developing software for executive control. 

First, hardwiue requirements needed to be determined. By exploring the general operational 
requirements of the UAV and uiking into account space and weight limitations, a hardware suite was selected 
which could provide adequate functionality to replace the human traits of a pilot. In order to provide 
“awiueness" of the operationtd environment, motion sensors, navigation equipment, and communication 
equipment wiis required. Controllable servo motors were necessary to move conffol surfaces appropriately. 
Computer hiudware, necesstiry to provide system intelligence, was selected in order to interoperate with the 
other hardware. Next, a Real-Time Executive (RTE) software program was designed to provide the 
functionality iuid coordination of idl hardware components. Device drivers for each component were 
developed, and overall coordination was planned using a Yourdon style essential model. Periodic interrupts 
were used to control execution time. Last, the specifications and configuration of all hardware components 
were completely documented, and the operation of the RTE program is fully explained. From this 
understiuiding of the overiUI control system, future development can continue, resulting in a more effective 
and efficient UAV design. 
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I. INTRODUCTION 


Control is defined as “the right or prerogative of determining or governing” [Ste73]. The control of any 
moving entity requires a correct determination of the current state of that entity followed by the careful 
governing of actions taken to correct any deviation from a given desired state. In an aircraft, this function is 
usually done by a human being. When removing the pilot from the aircraft, this control falls to a coordinated 
system of hardware and software called a controller. This controller must be built around some source of 
intelligence, whether it is remotely linked to a huinan, or intelligent in its own right. In addition, the controller 
must have the capability to cretite tutd govern the necessary changes in the aircraft’s state. Since the 
contfoller’s roles are so varied and yet interrelated, there are many design options to consider - the 
pennutations of which comprise many possible, workable solutions. 

A. RESEARCH OBJECTIVE 

This resetu-ch examines the design tuid synthesis of a controller for an unmanned air vehicle (UAV). 
The primary resetuch question is "What is required to build a central controller for an UAV?” A central 
controller is differentiated from tiny other auxiliary conttollers that may be on board in that the cenUnl 
controller governs the actuiU flight control of the aircraft This primary research question encompasses both 
htudwtue and software requirements, and leads to additional questions; 

• What sensors will be used to provide information about the state of the aircraft, in the absence 
of human senses? 

• Whtit is the fonn tmd limitations of the data provided by these sensors? 

• What aerodynamic surfaces tire available to conuol the aircraft? 

• What devices tire avtiilable to move the control surfaces, and what signals are required to cause 
these devices to move those .surfaces? 

• How must the movement of these conUoI surfaces be coordinated to control the aircraft in its 
six degrees of freedom? 

• Does the UAV need to communicate with any external facilities? 

• If the UAV does need to communicate with external facilities, how should this be 
accomplished? 

• What !uc the format and buffering requirements for this communication link? 

• What other input iuid ouqmt (I/O) of data is required? 

• What are the timing constraints for all command, control, and communication operations? 

• What hardwiue is necessary to achieve this functionality? 

• What iue the soflwiue requirements to interact with the chosen hardware? 

With these questions in mind, the ptirtimeters of operation and the system requirements for a UAV conuoller 
rue investigated. Tire specifications and configuration of the hardware and software used are fully 





documented. The goal of this resetuch project is a functional UAV controller, including a comprehensive 
Real-Time Executive softwine program fully integrated with the necessary hardware. 

B. PREVIOUS AND CONCURRENT RESEARCH 

Some of these questions tuive already been answered. This multi-faceted project is being developed in 
several previous and concurrent research programs, bringing together disciplines from Aeronautical 
Engineering; Mechanical Engineering; Electrical Engineering; Command, Control and Communications; and 
Computer Science. The airframe w;is aerodynamically analyzed and modified by Stoney [Sto93]. Significant 
to this resetirch was the addition of a canard on the front of the aircraft, which included two additional control 
surfaces. The servo motors used to move these imd other control surfaces were examined by Merz [Mei92] 
!uid Moran [Mor93]. They developed a core control system for the aerodynamic control vanes. Two 
datalinks have been developed to facilitate the transfer of data to and from a ground station. Reichert [Rei93] 
designed a wide-band UHF system and Bess [Bes94] tested a spread spectrum datalink. For navigation. 
Twite [Twi94] developed a differential GPS navigation system, and Hallberg [Hal94] investigated the inertial 
mettsurement unit (IMU) which w;is used. Mtuquis [Mar93] designed a complementary Kalman filter to 
blend the outputs of these two sensors, and the control algorithm has been wwked on by Davis [Dav92], 
Kuchenmeister [Kue93], Hiillberg [Hal94], :u)d Moats [Moa94]. 

C. EXECUTIVE SUMMARY 

This document consists of five chapters, including this Introduction. Chapter II provides a generic 
overview of the controller, discusses required functionality, and develops an essential model of this 
functiontdity m order to better understiutd the constraints and criteria under which it must operate. Chapter 
111 fully d(x;umenLs the specifications imd configuration of idl hardware used for the controller. It is intended 
to provide information in sufficient deliiil such that a new user would understand how to duplicate the existing 
hiirdwiire system upon receipt using similar equipment. Chapter IV fully documents the RTE software 
written for this project. This includes compiler information to enable a new user to recreate the software 
development environment under which the software was created. Chapter V delineates the conclusions 
drawn from this research ;md provides recommendations for future improvements to the system. Appendix 
A contains a listing of the source code for the RTE. Appendix B contains a glossary listing of all variables 
used in the RTE program. Finally, Appendix C contains the manufacturer s technical data sheets for the 


h:irdw:ue used for ihe controller. 






This reseiirch project will tie together the many individual sub-systems that have been designed for the 
UAV ;uid provide the metins for their operational use and coordination. Additionally, this research stands as 
proof-of-concept for UAV technology, especially for vertical take-off and landing (VTOL) aircraft that can 
transition to horizontal flight. This characteristic makes it especially useful for shipboard deployment, which 
will benefit not only the Deptutment of Defense, but also the U.S. Coast Guard by providing a cost-effective 
and fatigue-resistant solution to mtmy airborne missions, such as Search and Rescue and Law Enforcement. 





II. BACKGROUND 


This chapter provides background information detailing the objectives introduced in the last chapter. 
In this cluipter, a generic overview of a controller is provided, design considerations are discussed, and a 
Yourdon style essential model [You89] is developed. Within this model, parameters and priorities unique to 
this system are investigated. Since it is a real-time system, timing and intra-process communications are 
detennined. This analysis results in a more effective and efficient controller design. 

A. SYSTEM OVERVIEW 

In order to control the aircraft, a controller must have access to all information pertaining to the 
operation of the airframe, including: 

• Present and desired geographic position 

• Present and desired altitude 

• Present and desired tiirfnune attitude (in 3 dimensions) 

• Present jiirframe ticcelenuion (in 3 dimensions) 

• Present suite of power plant, including throttle and fuel suite 

• Present suite of payload equipment and desired operation of such equipment 

Then, a conuviler must be able to properly manipukite this information, develop signals to modify the 
physiciil configuration of the tiircraft’s conuol surfaces, and effect necessary data communications. To 
accomplish these results, a controller must maintain control over the following: 

• Signals that control each of the tiircraff s control surfaces 

• Signals that contiol the power plant (throttle) 

• Signals that conuol die ptiyload equipment 

• Communication chiuinels with ground control and/or monitoring sUitions 

In a digiud controller, these signals lue processed by a .set of software algorithms, interacting with specialized 
hardwtue. This set of tdgorithtns comprises a Retd-Time Executive program; the hardware includes sensors, 
servos, and communication equipment. As detailed by Moran [Mor93] and in Chapter III, the Archytas 
airfnune uses the following components to meet these requirements: 


I. Aireraft Sen.surs 

The UAV needs specitilly designed sensors which can generate signals in response to position, 
posture and acceleration of the aircraft. Among the sensors with which the processor must interact are: 

• Globtd Position System (GPS) Satellite Receiver 

• Inenitd Navigation System (INS) Instruments 

• Other (Non-INS) Flight Instruments 

• Fuel Sensor 






The GPS receiver yields a time stamp tmd a 3-dimensional position, including latitude, longitude, and 
tiltitude. The INS instruments include accelerometers that measure linear acceleration in each of the three 
dimensions, roll-rate sensors that metisure iingular velocity about each of the three coordinate axes, gjros that 
indicate aircraft heading, iind vertictd inclinometers that measure the angle of tilt from vertical. Non-INS 
instruments include a pitot tube airspeed indicator and a barometric altimeter. These sensors are “strapped 
down” which means they are fixed in alignment with the body coordinate system, the 3-dimensional 
coordinate system that uses the body of the aircraft as a reference. They detect acceleration, velocity or 
displacement in a certain direction, in reference to the aircraft itself. To be useful, these signals must be 
converted to the coordinate system of the environment surrounding the aircraft, called the inertial coordinate 
system. This conversion involves only a btisic m.itrix rotation, but can demand significant processing time. 

2. Aircraft Components 

In fiddition to the sensors, the eontfoller has several extrinsic components with which the 
processor must interact. These include: 

• Pulse-Width Modulated Servos 

• Communications Link 

• Payload Equipment 

Tile servos tire elecuic motors that position tiircnift controls as determined by the length of a received square 
pul.se. The communication link is usually a radio datalink transmitting digital data It provides two-way 
communication with the UAV, uplinking control information (commands) from the ground control station, 
and downlinking flight instrument daui to a ground monitoring station. Payload equipment includes cameras, 
radar, and other sensors not necessary for flight control, but used to complete the assigned mission. 

3. System Block Diagram 

The components iuid sensors OTe merged together to form an integrated flight control system, as 
shown in Figure 11-1. The most basic UAV controller must be able to perform the following functionality; 

• Receive digital sensor inputs 

• Perfonn antilog to digiud conversion of all analog sensor inputs 

• Provide digiud filtering for sensor data 

• Accept and process joystick and/or waypoint pilot commands from the uplink 

• Using input above, calcuhite control functions and determine control surface positions. 

• Generate appropriate command pulses and transmit them to servos. 

• Relay necessity posture and navigation information to ground through downlink 







The software components of this system are the Kalman filter and the control algorithms. The Kalman filter 
is an algorithm that smooths the sensor data to provide the most reliable source of data input, based on the 
varying accuracy of given sensors over different periods of time. The control algorithms are based on 
aerodynamic properties specific to the UAV. These algorithms compare the posture and position of the 
aircraft to the desired posture <ind position, and determine what corrective actions must be taken. These 
softwiffe functions, in addition to the transfer of all data and signals coming from or going to the central 
processor (shown as arrows to tind from the shaded area in Figure Il-l), comprise the Real-Time Executive - 
- the software component of the controller. 



Figure 11-1: System Block Diagrai 













































4. Assumptions 

Since this project is btised on the work of several students working concurrently, the scope of the 
controller’s functionality for this research is limited by several assumptions. All of these assumptions can be 
substimtiated once the conu-oller is fully completed and tested on the aircraft in flight. 

a. Filtering and control algorithms exist as system callable subroutines. 

The filtering and control algorithms are specialized aeronautical engineering routines which 
involve additionid resetirch, such tLs linear quadratic filter design and wind tunnel testing, which is being 
accomplished by other students. For this project, it is assumed that the resulting routines will exist and can 
execute within the allotted time constraints. 

b. Input and output (I/O) will not require central processing resources. 

Digital IA5 will take place through eight 25-ptn RS-232 serial ports. These ports reside on a 
separate circuit board that has its own small processor. Although I/O must be initiated by a subroutine call 
from the main controller program, the processing required to execute and control the data flow is handled by 
this sub-processor tuid so will not require cenual processing resources. This form of parallel processing 
greatly reduces the amount of processing time required for this function. 

e. Air to ground communications will not require central processing resources. 

The radio datti link htudware on hand conducts its own handshaking, parity checking, and 
other data communication functions. Since it will connect to the I/O ports, this function is actually twice 
removed from the controller itself. Even with an assumed 1S% protocol overhead, the datalink is expected 
to hilve sufficient throughput to avoid becoming a bottleneck in the communication process, without 
requiring central processing resources. 

d. The sensors’ data stream will be fast enough to provide fresh data for every cycle. 

It is impenitive that the digiud dtiui from the Inertial Measurement Unit (IMU) is current and 
complete eveiy control cycle. Additionally, sensor data which is not digital must first be converted from 
analog to digital (A/D) through a stunpling A/D circuit board. This A/D process is done in hardware and will 
not affect the perfonnimce of the controller. However, if this A/D process takes too long, the most recent data 
from the A/D card may not yet he available when retid by the controller. It is assumed that current and 
complete sensor data will be available when needed for each conn-ol cycle. 






e. The controller’s processing speed will be sufficiently fast to perform aUfunctions. 

No matter how fast a processor is, it has a limited throughput. It is assumed that the CPU can 
perform idl required functions in the allotted retd-time interval. If this assumption proves false, the present 
processing speed of 33 MHz will have to be upgraded. 

B. DESIGN CONSIDERATIONS 

In the design of a real-time system, it is important to understand the constraints, structures, and 
parameters of the system, its well as other design choices that are avtiilable to the designer. It is the 
combination of these design choices that determines the successfulness of the resulting system. This section 
detiuls the consu^aints imposed by a retd-time system, lists options for programming structure, and discusses 
considerations for the selection of a programming language tmd fault tolerance measures. 

1. Real-Time System Constraints 

The tenn real-time covers a wide range of systems: however, all systems share a common feature 
where results of some kind are demtmded by timing deadlines imposed by the environment outside the system 
[Sav85]. As time mtaches relentlessly onwttrd, all system and subsystem responses must fit within their 
allotted lime fnunes. A real-lime system can idso be described as reactive or embedded. Reactive systems 
rue those which have some ongoing interaction with their environment. Embedded systems are those used to 
control speciidized hardwtae in which the computer system is installed. Since the UAV controller will 
cont'muously monitor tmd interact with the position and posture of the aircraft within its environment and will 
also simulumeously control specialized hardware, it is both a reactive and an embedded system. 

It cim be argued that :dl practictd systems are real-time systems. Even a word-processing system 
must respond to user commtmds within a retisonable amount of time {e.g. 1 second), or it will become torture 
to use. Most literature refers to such systems :is soft real-time systems - systems where performance is 
degraded but not destroyed by failure to meet response time constraints. Systems in which failure to meet 
response lime conshtiinls lettds to potential complete system failure are called hard real-time systems. Under 
these definitions, the UAV controller is a hiird retd-time system under which missing a deadline could lead 
to complete loss of control. Therefore deadlines, once established, become constraints inside which the 
system must operate completely. 

To meet these constraints, three measures of time, when applied to real-time systems, must be 
Ciirelully intmaged: re.sponse lime, survivtd lime, tmd throughput [Sav85]. Each is defined below. 
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a. Response Time 

Response time is the time the computer takes to recognize and respond to an external event. 
This is the most important time meiisurement in control applications. If events are not handled in a dmely 
fashion, the system may literally go out of control. The UAV must not only respond to pilot commands, but 
must continutUly monitor feedback signals from the servos rmd inertial navigation equipment to determine if 
the response resulted in the correct, desired effect. Experimental evidence suggests that a total response time 
from pilot input to final movement of control surfaces cannot exceed 100 msec without loss of positive flight 
control by the pilot [Kiun93]. 

b. Survival Time 

Survivid time is the time span during which data is available to be read. Since flight data is 
stored in a buffer, the data may be retid at any time that the buffer is not being written to. Read/write cycles, 
therefore, must be sufficiently offset such that the reading and writing of the same data will not h^pen 
simultaneously. The next consideration, then, is the validity of the data. Since the aircraft is anticipated to 
move at speeds of up to 150 kis, it is imporuint to have the latest sensor data available for every control cycle. 

e. Throughput 

Throughput is the total number of events which the system can handle in a given time period. 
For exiunpie, a communication controller may have a throughput expressed in characters per second. Since 
a large lunount of data must be relayed to the ground, the radio datalink must not be allowed to become a 
bottleneck wliich could slow the ceiitnil processor. The data stream must also be managed to flow evenly, so 
that there iu-e not bursts of daui in excess of the chimnel capacity interspersed among long periods of under¬ 
utilized capacity. In tuuilog to digital (A/D) conversions, the bandwidth of the digital signal (equal to the 
product of the stunpling rate iuid the siunpling width in bits) is usually much greater than the bandwidth of its 
amdog counterptirt. Accordingly, the UAV A/D processes must be fast enough to provide fresh, accurate data 
at the frequency needed by the controller. 

2. Structure Taxonomy 

The simplest kind of sol'twine structure for a retd-time system is a polling loop. The program 
exiunines (polls) each of its inputs in turn to determine whether an event has occurred which requires a 
response. This structure would be sufficient for die UAV if all polling was done at the same frequency. Since 
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this is not the case, a more complex, event-driven structure is needed. Event driven systems have three main 
types: interrupt driven, multi-tasking, or multi-processing (multiple processors) [Sav85]. 

a. Interrupt Driven 

In cin interrupt driven system, counters are used to keep (rack of inter-process timing, 
generating ;ui interrupt when it is time to begin a new cycle. At the occurrence of an interrupt, the controller 
saves its current state on the stack and jumps to the appropriate interrupt service routine (ISR). If the timer 
generates iui interrupt at regular intervals, tuid if the ISR is replaced by the control loop routine, it can be 
assured that the contfol loop will be executed regularly and consistently. However, for this to work, the 
execution time of the conUol loop must not exceed the interrupt time interval, or the subsequent ISR 
execution wilt interrupt the current ISR execution, resulting in a backlog of pending processes on the stack 
tuid, eventually, a system crash. To get the most from each control cycle, the task load resulting from each 
cycle should be kept its level as possible. 

b. Multi-tasking 

Task management could be delegated to the operating system if a multi-tasking environment 
was tidopted. Multi-tasking, however, requires a large amount of processor overhead and brings with it its 
own unique problems when multiple tasks tae forced to work with the same data. Since multi-tasking is not 
available on the present operating system, this option wtis not considered. 

t. Multi-processing 

To a cermin degree, the UAV will have multiple processors, as mentioned in the 
iLssumptions. The benefit of multi-processing is in the ability to take the processing load for these functions 
off the central conuoller tuid to have them performed by a processor that is specially designed for that task. 
It is important to ensure that these auxiliary processors can access the same data buffers and to configure 
memory access such that no two can retid/write the stune dtiUi simultaneously. 

3. Programming Language 

"C” was chosen as the prognunming Itinguage for this project since it is almost unique among the 
high-level compiler languages in thtit it does not (usually) come in between the programmer and the machine. 
If something can be done in assembly language, there is usually a way to express it in C [Sav85]. For 
exiunple, in C one can directly mtinipulate machine registers. I/O addresses can be written to directly. 
Interrupt handling is also possible. Interrupt vectors cun be inspected and modified, and BIOS interrupts can 




be executed by a system ctill. Memory allocation can be directly controlled, and bit-level programming is 
possible. For any applications that cannot be completed in C, assembly language could be used. 

4. Fault Tolerance 

Fault tolerance, or system robusUiess, is the ability to recover from errors or system failures. With 
tm interrupt-driven system, provisions must be made for detecting and covering for a missed deadline. This 
can be done by spatial or temporal methods [Lap92]. Spatial fault tolerance includes redundant hardware and 
software systems. Temporal fault tolerance involves careful design of algorithms to compensate for missed 
detidlines. Since hardwttre on the UAV must be kept to a minimum, most of this redundancy must occur in 
the software. Although this will add to the overall complexity and detract from the overall efficiency of the 
system, the nature of the mission requires this redundancy. In addition, execution time for the fault tolerance 
overhead must not cause timing constraint violations in an otherwise correct system [Nel92]. Timing, 
execution tuid resource constraints dictate the following provisions for any module, regardless of the language 
that is used [Sta88]: 

• Modules should have predetermined and bounded execution times. 

(recursion tmd loops must be used carefully) 

• The use of dyntunic structures should be controlled. 

• For predictable system behavior, provision should be made for all known types of exceptions. 

In addition to the nonntil programming exceptions, the RTF for the UAV also has to deal with external 
mtdfunctions, such as equipment failure, miinual system reset, or loss of communication with the ground 
stittion. 

C. AN ESSENTIAL MODEL 

From the foregoing descriptions and specifications, it is possible to construct an essential model of the 
sy.stem. including a context diagnun, tm event list, leveled data-flow diagrams and state transition diagrams 
[You89J. Process specifications may be gleaned from the requirements discussed previously. 

1. Context Diagram 

It is necessiuy for the controller to interact with many varied components, as evident from the 
system block diagram. The context diagnun in Figure II-2, shows the context in which the controller must 
operate. The circle in the center represents the controller. Entities diagrammed outside the circle represent 
sy.stems outside of the controller’s retdm of direct control, even though the controller communicates and 





dicuites timing constraints with them. The buffer, datalink,and track log, diagrammed with a line above and 
below, represent data storage requirements. The arrows represent the transfer of data between systems. 



Figure II-2: Context Diagram for UAV Controller 
2. Data-Flow Diagrams 

Data-flow diagnuns (DFDs) are graphical representations depicting the system as a network of 
funclioniJ processes <uid immifesling the interactions of data flowing between those processes. Although just 
one of m:my modeling uxils. DFDs ;ue commonly used for operational systems in which the functions of the 
system ;ue of piuamounl imporltmce mid more complex than the data that the system manipulates [You89]. 
The lop level DFD Ls followed by sub-level DFDs that further break down the functionality of the top-level 


processes. 






































a. Top Level 


The top level data-flow diagnun (DFD) for the UAV shows the interaction of all of the major 
processes. As shown in Figure II-3, the controller responds to pilot commands or waypoints, determining 
control actions and providing feedbtick to the pilot’s control display, which completes the control loop. 



Figure II-3: Top Level Data-Flow Diagram for UAV Controller 



















b. Single-Process Sub-Level Data-Flow Diagrams. 


Many processes in the top level DFD have only one process in their sub-level which just 
explains the function of the top-level process in more detail. For example, the following processes simply 
read data from a buffer or A/D port and pass it on without processing: 

4.1 = Read digittd represenuition of fuel level from A/D port 

5.1 = Read digital INS .sensor dtitti from buffer. 

6.1 = Read digital GPS fix daui from buffer. 

7.1 = Read digital representation of Non-INS sensor data from A/D port. 

12.1 = Record position in Track Log. 

Three other sub-level DFDs can be described by one process; however, that this process is 
slightly different depending on the mode of flight. The UAV can be flown directly by a pilot using joystick 
control or autonomously following a pre-established list of latitude/longitude/altitude waypoints. 


TABLE II-l: Process Comparison by Flight Mode 


Process 

Direct Control Mode 

Autonomous Hight Mode 

2.1 

Read joystick position 

Retrieve lasl/next waypoints 

3.1 

Convert composite com¬ 
mand into vectored com¬ 
mands for each of 3 
reference axes (X,YZ) 

Calculate trackline of accept¬ 
able positions between the two 
given waypoints. 

10.1 

Call Linear Quadratic 
routine (Assumption 1) 
to determine corrective 
control surface positions 

Calculate corrective trackline 
and, (10.2) call Linear Qua¬ 
dratic routine to determine cor¬ 
rect control surface positions. 


c. Multi-Process Sub-Level Data-Flow Diagrams 


Lastly, the multi-process sub-level DFDs are shown below: 
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Multi-Process Sub-Level Data-Flow Diagrams (con’t): 





Figure 11-6: Process 9.0, Determine Position and Posture 













Multi-Process Sub-Level Data-Flow Diagrams (con't): 



The event list looks deceptively simple. All events are temporal with the exception of 
asynchronous joystick inputs from the pilot, but since the command inputs are polled, this event also becomes 
teinpond. Each event is either ptirt of the control cycle or runs on its own frequency which would be an even 
multiple of control cycles. The chtdlenge is to keep cycles of different durations from becoming out of synch 
and infringing on each other’s resources. The controller must handle the following event parameters; 

Pilot inputs new joystick command. 

Pilot coinintinds mu.st be polled once per control cycle. 

INS daui needs to be read once per conbol cycle. 

GPS input needs to be rctid once per .second. 

Non-INS dtila needs to be reitd once [ter control cycle. 

Each of eight control surface servo command pulses must be generated each control cycle. 

The throttle servo command pulse must be generated once per second. 

The fuel level needs to be re.id every 60 seconds. 

The conuol display must be updated iit least twice per .second. 
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4. State Chart 


After considering m;iny possible formats to depict state transition information, state charts 
appeared to best represent the orgiuiiztttion of the UAV controller. Developed by D.H. Harel, et al [Har90], 
state chiirts combine the state transitions of stiindtad state transition diagrams with process depth typically 
represented in Warnier-Orr diagrams and then add elements of orthogonality and communication. 
Orthogonality, represented by a dashed line, indicates separate tasks, and communication, represented by 
tuTows, is a method for allowing different orthogonal processes to react to the same event [Lap92]. 



Figure 11-8: UAV Controller State Chart 


























































D. CHAPTER SUMMARY 


As an unmanned vehicle, the UAV developed at the Naval Postgraduate School is completely 
dependent upon its automated systems to provide control of the aircraft in flight. Directing the execution of 
these automated systems is a controller running a Real-Time Executive program. The conect operation and 
reiU-time coordination of all functions on board the aircraft depends on their interaction with this controller. 

At present, the UAV is designed to have tin on board GPS receiver, an inertial measurement device, and 
other in-flight sensors. Appropriate dtiui must be selected from this navigation suite, filtered, and analyzed 
to detennine the current state of the aircraft at any given time. This state may have to be converted into a 
different referential coordinate system. Processing this state via appropriate control algorithms will yield 
corrective positions for the avtiilable conu-ol surfaces and the throttle. These controls are moved by pulse- 
modulated servos, which require a pulse of a specified width be generated and output at a precise time. Pilot 
comintuids must be received tind the aircraft stale may be transmitted through a communication link, using 
appropriate protocols. Data acquisition, processing, and I/O must be repeated at various intervals and 
coordinated through a Retd-Time Executive (RTE) software program. This RTE is driven by a periodic 
interrupt and must be robust. The main challenge is to coordinate the complex scheduling of these executed 
functions to yield smooth and positive control of the UAV. 
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III. HARDWARE 


Hardware selection represents a challenging task. Choosing from the myriad of possible systems and 
configurations, each with their own cost, advantages, and disadvantages, it is easy to underestimate the 
ultimate significance of that selection. Indeed, the hardware selected determines most, if not all, of the 
system’s limitations. It impacts the flexibility of the system and the programmer’s control over the system. 
It determines the method by which things can be accomplished on or by the system. 

For the UAV controller, the selection of hiudware was largely made prior to this research. In general, 
it was constrained by the following criteria: 

• The manufacturer should be from the United States, local if possible. 

• All hardware should come from the same manufacturer, for interoperability purposes. 

• Therefore, the manufacturer should offer hardware to meet all requirements. 

• The composite hardware solution should be modular, for ease of upgrading and maintenance. 

• The hardware must be immediately available (not under development). 

• The hardware could operate on a standard +/- 5V and +/- 12V power supply. 

• The composite hiudware solution would fit within the space available on the UAV. 

• The composite hardwtue solution would have minimal weight. 

• The hiudware could execute commercially available software, including a C compiler. 

The reasoning behind choosing an American manufacturer was that if there were any hardware related 
problems, iui American miuiufiiclurer, especially one with an office in the local area, would be easiest to 
contact itnd could provide the quickest response to requests for technical assistance. A specific operating 
system was not originally selected, but defaulted to MS-DOS because of the low cost and wide availability 
of compatible htudware and .softw:ue. The choice of MS-DOS precludes the use of multi-tasking scheduling 
strategies, but it was determined that multi-tasking would not be required, at least for the first iteration of the 
controller. 

Ultimately, all controller hiudwiue wits purchased from American Advantech, Inc. Their offices and 
technical staff lue located in Sunnyvale, CA. This chapter delineates the most prominent features of the 
hiudwiue selected. It lists selected specifications for the chosen hardware and discusses the configuration of 
that htudwiue as designed for the conuoller applications. These configurations have been carefully selected 
to get maximum perfonnance and complete interoperability out of each system component. Numbers listed 


FC Advantech model numbers. Technical data sheets iue given in Appendix C. 







A. SYSTEM OVERVIEW 


Figure III-l shows the configuration and connectivity of the overall hardware system. The oval shape 
represents components that are needed for development only and are detached prior to installation. The 
remaining components must be mounted on the UAV, most inside the control pod designed by Moran 
[Mor93 J. Raceunck shapes represent sensor iind navigation subsystems, most designed through the research 
of other students and incorporated into this controller design. Rectangular shapes indicate circuit cards or 
power supplies, most from Adviintech, that comprise the central part of the controller. The specifications and 
configuration of each component is described in this chapter in sufficient detail such that a new user would 
be able to recreate tmd undersUuid the present hiudware system. 



B. PCA-6108: PASSIVE BACKPLANE 

This is primiu-ily :ui exiernal bus. facilitating communication and data transfer between all other 
hiudwiue components. The other computer circuit boards plug directly into each of the eight, PC/AT 
compatible exptuision slots. Tliis ctud hits ti heavy duty, suuidard block connector for the power supply, 
making +.‘5V, +12V, -12V. and system ground availiible to all cards. 
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C. PCA-6146: CPU CARD 


1. Specifications 

This board contains the central processor, an Intel 80486 running at 33 MHz with SKbytes of 
cache on-chip, 256 Kbytes of 25ns double cache memory and 16 Mbytes of DRAM. Also included on the 
boiod tire tincillary electronics to support processor functions, such as the Peripheral Interrupt Controller 
(PIC), Universal Asynchronous Receiver tind Transmitter (UART) and counterAimer chips. The board 
interfaces with the backpltute through a 32 bit ISA bus operating at 8 MHz. Control circuits on the board 
support two floppy disk drives, two IDE hard disks, two RS-232 nine-pin serial ports, one 25-pin parallel port, 
and a keyboard port. Significant for this research, it features a 4-bit (15 level) interrupt vector and a 
prognunmable watchdog timer. The watchdog timer ensures that the CPU will be reset if a program cannot 
be executed normally, which is useful in retd-time systems where a program or power glitch could lock up 
the system. The maximum power requirement for this board is approximately 2.5 A at +5 V. 

2. Configuration 

The CPU card has been configured to support parallel port LPT2, serial ports COMl on the upper 
port and COM2 on the lower port, and the floppy disk controller. To accomplish this, the J1 jumper pins must 
be set as shown in Table III-1. Next, allltough the controller functions without a hard disk, one is needed for 
softwiuie storage during the initiid prognunming. Thus, jumper JP17 must be enabled (open). The watchdog 
timer is enabled by closing jumper JP22 and leaving JP23 and JP24 open. The timer interval is set by closing 
either JP19, JP20, or JP21. Due to the nature of this application, a timeout of 1.5 seconds was selected. 
Should a power drop, software bug, or infinite loop halt the system, the aircraft would be without positive 
control for a maximum of 14 seconds, including a total rebooting time of 12 seconds. 

When connecting the CPU card to tut external panel display, attach the lead wire for hard disk 
indicator light (usually red luid black) to the HD connection next to the red LED at the top of the CPU card. 
Attach the lead wire for the turbo light (usually yellow and black) to JP5. The lead wires from the reset switch 
(usutdiy red ;ind black) connect to JP4. and the keylock connection is made at made at JP3. Pins 3 and 5 of 





JP3 are ground connections, so the black wire should be at the bottom of the connector. Incidentally, pin 1 
of JP3 is LED power, and pin 4 controls the keyboard lock. 


TABLE ni-1: CPU Card Jumper Settings 


Jumper 

Setting 

Jumper 

Setting 

JPl/1 

Close 1-2 

JP14 

Close 2-3* 

ma 

Close 1-2 

JP15 

Open* 

JPl/3 

Close 1-2 

JP16 

Closed* 

JPl/4 

Close 1-2 

JP17 

Open 

JPI/.S 

Close 1-2 

JP18 

Open* 

JPl/6 

Close 1-2 

JP19 

Closed 

JPl/7 

Close 1-2 

JP20 

Open 

JP7 

Close 2-3* 

JP21 

Open 

JP8 

Close 2-3* 

JP22 

Closed 

JPll 

Close 2-3* 

JP23 

Open 

JP12 

Close 2-3* 

JP24 

Open 

JP13 

Close 2-3* 




* Denotes factory setting 
3. Ba.sic Input Output System (BIOS) 

For the system to work properly, the stctual hardware and memory configuration must match the 
•setup configured in the non-volatile BIOS chip. This is a CMOS memory chip by American Megatrends, Inc. 
which stores the system configuration tind is retid by the processor each time the system reboots. To access 
the BIOS tfcita. press the DEL key during the inititd stages of the bootstrap process, while the processor is 
checking the avtiilable memory. The progrtun will present a main menu from which the user may choose 
CHIPSET setup, standtud CMOS setup, or advtmced CMOS setup. For this research, no changes are 
necesstu-y to the CHIPSET setup-, idl factory default values are used. 
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In the standard CMOS setup, values entered must correspond to the actual hardware in use. For 
this research, u 102 MB hard disk and a 1.44 MB, 3.5 inch floppy drive are used. Accordingly, hard drive C 
is set to USER TYPE 47. This should correspond to the following data fields: 


TABLE ni-2: Hard Drive C Parameters 


Cyln 

Head 

I WPcom 

LZone 

Sect 

Size 

1024 

12 

1 1025 

1025 

17 

102 


When booting from the PCD-890 RAM Disk, no actual hard disk is used, so hard drive C must be changed 
to Not Installed. Hard drive D should always be set to Not Installed, floppy drive A should be set to 1.44, 
and floppy drive B may be set appropriately, if one exists. 

Among the many ptirameters set in the advanced CMOS setup, a few are important. The HD Data 
Areti should be set to 0:300. This should not be changed unless a different hard disk is used or if the present 
htuxl disk is reinitiidized. The System Boot Seq should be set to C:A:, which forces the system to boot off 
the hard disk, if one exists. Finally, till cache should be enabled, all video ROM shadow-RAM should be 
enabled, all adapter ROM shadow-RAM should be disabled, and the system ROM shadow-RAM should be 
enabled. 

D. PCD-890: RAM Disk 

1. Speciricatiuns 

The PCD-890 is a solid-state disk einuhitor with a ciipacity up to 12 MB, using EPROM, SRAM, or 
Fltish memory chips. For this resciuch, 24 Sony 581000P 128 KB SRAM chips were used to create a 2.88 
MB emulated disk. Repliicing mechanictd drives with the RAM Disk not only allows data retrieval to be 
accomplished five times faster, but the RAM Disk is also much less susceptible to damage from motion or 
vibration. Two PCD-890’s may be insudled on each system, and each PCD-890 has two memory banks that 
may be configured as either one or two virtuiil disks. Etich virtual disk can be configured as drive A, B, C, 
or D which tue fully .softwiae compatible with mechimictil drives with no additional software development. 
Each hoiud features a 3.6 V reckugeable lithium biUtery that keeps the SRAM charged and lasts up to six 
months. Memory loss is possible if this battery is allowed to run down; however, there is a connection at CN1 


■ an optional externtil battery power. Etich Ciad requires only 16 KB of system memory. 












2. Configuration 


The PCD-890 comes with a utility program which is used to load the on board BIOS chip with the 
present configuration. This configuration is dependent on the position of various dip switches and jumpers. 
Jumpers JPl and JP5 select the type of chips installed in each bank. Both of these should close the connection 
between pins 2 and 3 to denote SRAM. JPIO ;md JPl 1 set the size of the installed chips. These should also 
close pins 2 and 3 to denote 128 K or huger. Because there is only one PCD-890 installed, the JP9 jumper 
should close pins 1 ;md 2. To enable the SRAM battery, close pinsl and 2 on JP4. JP8 sets the interval of 
the wiitchdog timer, which is not used on this card. 

Dip switches SWI tmd SW2 :ue used to enable each bank and set its drive designation. Position 
1 imd 2 set the designation. Fur nonnal operation, bank 1 must be enabled, unprotected, and set to drive A 
so that the computer will boot from the RAM Disk in the absence of a hard disk (Recall this bootstrap order 
was established in the BIOS of the CPU card.). Since it is desired to have one contiguous memory space, 
biuik 2 must be disabled and cidled something other than drive A. Table 111-3 shows the switch settings used 
for this configuration. 


TABLE III-3: Switch Settings for PCD.890 



During system development, it Is often desirable to use both the RAM Disk along with a hard drive 
C and a floppy drive A. In this case, designate the RAM Disk as drive C by turning off switch 1 of SWI. If 
the PCD-890 is internidly designated the siune logical name as a hard disk existing in the same system, MS- 
DOS will automatically assign the PCD-890 to the next available DOS drive, in this case drive D. Note that 
the utility progriun will continue to refer to etich bank according to the jumper setting, not its DOS drive 
designiuion. Also, the BIOS on the CPU card must be updated to correctly reflect the presence or absence of 
the acluid hind drive. 

Finally. S W3 sets the memory and I/O addresses assigned to this card. These have been carefully 
selected to avoid conflicts with other hiudwiuc and system services. If two PCD-890’s are installed, they 
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must be set to occupy the same memory address (positions 1, 2, and 3 are the same on both cards), but 
different I/O addresses (positions 4,5, and 6 cannot all be the same). SW3 should be set as follows; 


TABLE III-4: Switch Settings for PCD.890 SW3 


The utility program can be invoked by executing the fde named 890 in the PCD-890 directory. 
Once the switches and jumpers have been properly set, the utility program should minor that configuradon. 
Drive A is listed its SJ2KB SRAM with a disk size of 2.88 MB. AU other entries should read Nol Installed. 
Pressing ESC will exit the prognun :md load the configuration into the BIOS chip. 

Once properly configured and plugged into the backplane, the PCD-890 will automatically install 
itself in memory during the booting sequence. The only indication will be a message similar to Figure III-2 
flashed on the screen for less than one second in between the RAM check sequence and the execution of the 
AUTOEXEC.bat file. To view this screen, press the Pause key to halt the bootstrap process. 

PCD-890 RAM/ROM DISK BIOS Rev. B1 (c) Copyright Advantech Co., Ltd. 1992 
Contiguration: I/O MEMORY 

Drive A: 2.88M RAM Disk formatted (write protect OFF) 0240 D400 
BATTERY IS GOOD 

Figure III-2; PCL-890 Installation Confirmation Message 
E. PCL-744: SERIAL I/O CARD 
1. Specifications 

The PCL-744 is an intelligent .serial data communications interface card. It provides eight 
iusynchronous, full-duplex RS-232 or RS-422 ports per ctud, and up to four PCL-744 cards may be used 
concurrently. It is equipped with a V20 (8088 compatible) 8 MHz CPU, which relieves the central processor 
of tJl data handling ;uid I/O flow conuol tasks. Transmit and receive queues are stored in a 64 KB dual-port 
RAM buffer, which frees m;iin memory and prevents data loss. Dual-port refers to the fact that data can be 
accc.ssed by both the centr:d processor and the on board CPU. This memory-mapped data transfer is generally 
much faster th;ui .sttuidtud memory I/O with data copying. Each card maps to only 8 KB of system memory. 


2.1 












The PCL-744 hiis a single DB64 female pon which connects to a special "octopus” cable 
branching out into eight DB25 male connectors. Each of the eight ports features complete modem flow 
control signals (RTS, CTS, DSR, DTR, and DCD) and operate at a programmable communication rate 
nmging from 50 to 38,400 bps. The PCL-744 uses four 2681 DUART (Dual Universal Asynchronous 
Receiver :uid Transmitter) devices, with etich 2681 conbolling two ports. These two ports share one baud 
rate divider, which is clocked by a 3.6864 MHz crystal. Baud rates may be selected for each of the two 
chtinnels independently, but becau.se of the shtued divider, both rates must be from the same group: 


TABLE III-5: Baud Rate Groups (bps) 


Group 1 

1200,2400,7200,9600.38400 

Group 2 

1200,1800,2000,4800,9600,19200 


The PCL-744 selects its IRQ level automatically in software and requires a maximum of 1.5 A at 
5 V, 120 mA at 12 V, iuid 170 mA at -12 V, the latter necessary for RS-232 signalling. 

2. Configuration 

The PCL-744 hits no jumpers or switthes. Configuration options such as the number of cards, 
IRQ channels, port numbers, and memory buffer starting addresses are all selected using the setup program. 
To run the setup program, execute the program named SETUP in the PCLS-802 directory. Choose the 744 
intelligent ciud choice to get to the PCL-744 setup screen. On this screen, set the select IRQ number to JO 
hex iuid the select duiU port biuik loAUTO. Tlie st:iit port should be set to 03. This is because the two COM 
ports on the CPU ctud hecoine ports I and 2 by default. Pressing page-down gives access to the port 
configuration menu. The Croup Edit function ensures that all ports are configured identically. Ports 3 
through 10 correspond with octopus cable connectors 1 through 8. and are configured as shown in Table III-6. 

To install the PCL-744 driver, execute the file 744-DRV.exe in the PCLS-802 directory. If it 
installs correctly, the following message appears: 

PCL-ConrtUb Communications Driver (Ver 3.00) 

PCL-744 Multiport Card 1: No [05477) Bank[C800J Port [03-10] IRQ 10 

Device Driver Setup O.K. 

Figure I1I-3; PCL-744 Installation Confirmation Message 

Executing the file STD-DRV.exe will tilso enable control of COMl and COM2. Both of these 
executions :ue done automatically trom the AUTOEXEC.bat program during system bootstrap. 
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TABLE UI-6: PCL-744 Serial Port Settings 


Ext R\D Biif .Size 

2K 

Baud Rate 

9600 

C httracter Length 

8 

Stop Bits 

1 

Piirity 

None 

DTR Output State 

Off 

RTS Output .State 

Off 

CTS Flow Control 

No 

RT.$ Flow Control 

No 

IxXON/OTCntrl 

No 

RxXON/OFFCntrl 

No 


F. PCL-812PG: ENHANCED MULTI-LAB CARD 
1. Specifications 

The PCL-812 is a high speed, inuUi-l'unction data acquisition card used primarily in this project 
to accomplish antUog to digiud (A/D) data conversions. It features: 

• 16 single-ended analog input chiuinels 

• Switch selectable bipohu antUog input voltage ranges 

• A programmable Intel 8253-5 timer to provide internal pacer (trigger) pulsing 

• Choice of internal or external reference voltages 

• A PCLD-780 wiring terminal bretikout botud for ease of connection 

• Callable softwcire drivers for :dl ctud features 

• TTL compatible I/O signal levels 

Single-ended iuialog inputs require only one signal wire for each channel. The voltage is 
inetLsured with respect to common (system) ground. A signal source measured with respect to a reference 
other than common ground is a floating source. For these signals, a second input called analog ground 
(A.GND) is avtiilable. 

The PCL-812 uses an industri.d sttmdiird 12 bit successive approximation converter (HADC574Z) 
to convert analog inputs. Typictil A/D conversion time is 25 usee. Because an 8 bit register cannot 
accommcKliite all 12 data bits, the A/D data is stored in two registers located at the base address 44 and +5. 


27 



















Tile leiist signiticiint bits are in positions U (ADO) through 7 (AD7) of BASE +4, and the most significant bits 
!uc in positions 0 (ADS) through 3 (ADI 1) of BASE +5, with ADll being the most significant. Other 
iinporitmt I/O addresses tue shown in Table 111-7. The PCL-812 requires 16 consecutive bytes of address 
space luid typiciilly draws 500 mA at +5V, SOinA at + 12 V, and 14mA at - 12V. 


TABLE ni-7; PCL.812 I/O Address Map 


Loctition 

Read Function 

Write Function 

Base Address 

Counter 0 

Counter 0 

Base + 1 

Counter 1 

Counter 1 

Biise + 2 

Counter 2 

Counter 2 

Ba.se + 3 

Not Used 

Counter Control 

Base+ 4 

A/D Low Byte 

Ch 1 D/A Low Byte 

Base + 5 

A/D High Byte 

Ch 1 D/A High Byte 

Btise + 6 

D/1 Low Byte 

Ch 2 D/A Low Byte 

Base + 7 

D/1 High Byte 

Ch 2 D/A High Byte 

Base+ 8 

Not Used 

Clear interrupt Request 

Base + y 

Not Used 

Voltage Gain Control 

Base +10 

Not Used 

Mux Control 

Base+11 

Not Used 

Mode Control 

Btise+12 

Not Used 

Software A/D Trigger 

Base+13 

Not Used 

D/0 Low Byte 

Base +14 

Not U.sed 

D/OHigh Byte 

Base+15 

Not Used 

Not Used 


2. Configuration 

The base address lor (he PCL-XI2 is selected using the first six switches of SWl, located at the 
top of the circuit Ixiiird. These should be set as shown in Table 1II-8, giving an I/O address of Hex 220. 


TABLE III-8; Switch Settings for PCL-812 SWl 


8 

On 
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Switches 7 and 8 ofS W1 control the number of wait states added to the PCL-812 to achieve stable 


data tnuisfer. It Ciin be configured with zero, two, four, or six wait state delays for each transfer of data. Both 
switches turned on selects zero delay. Jumpers are used to select the remaining configuration options. 
Table 111-9 shows the present settings imd their function. 


TABLE III-9: PCL-812 Jumper Settings 


Jumper 

Setting 

Function 

JPl 

Close 1-2 

Use internal A/D conversion bigger 

JP2 

Close 1-2 

Use internal 2 MHz clock for counter channel 0 

JP3 

Close 1-2 

Use internal voltage (JP8) for D/A reference on Ch 1 

JP4 

Close 1-2 

Use internal voltage (JP8) for D/A reference on Ch 2 

JP5 

Close contact 5 

Select 1RQ5 to signal A/D completion 

JP6 

Close contticl X 

Select no DMA data transfer (DRQ Channel) 

JP7 

Close contjict X 

Select no DMA data transfer (DACK Channel) 

JP8 

Close 2-3 

Use -5V for internal D/A reference voltage 

JP9 

Close 2-3 

Select +!- 5V for maximum A/D conversion range 


If JP9 is set to -r/- .S V, the iuialog input ranges available for A/D conversion are +/- 5V, -f/- 2.5V, 
-s/- 1.25V, +/-0.625V, or-s/- 0.3125 V, dependent on a softwiire gain code parameter. These ranges could be 
doubled by setting JP9 to +/- lOV, but only if Vcc of the system power supply is strictly greater than 12V, 
otherwise A/D conversions will not be correct. The output of the present power supply is only 11.8V. 

Analog connections lue made through connection ports CNl and CN2 on the slot edge of the card. 
Figure 1II-4 shows the pin tUignment for etich connector. For this research, a PCXD-780 wiring terminal 
breitkout botu’d w;is used to connect signtd wires to the ports through ribbon cables. 



Figure III-4: PCL-812 Connection Port Pin Alignments 
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Prior to using the Lab Card, it is necessary to install the PCL-812 driver by executing the file 
PCL 812.exe in the PCL-812 directory. The computer will confirm correct installation with the message, 
"PCL-812 Driver Version 1.0 is now in.stidied.” This execution is also done automatically from the 
AUTOEXEC.bat prognun during the system hootsuap process. 

3. Calibration 

For accurate results, the A/D inputs must be properly calibrated. Five variable resistors (VRs) on 
the PCL-812 allow accurate adjustment. VR3 and VRS are used for A/D adjusunent, VRl and VR2 are used 
for D/A adjustment, and VR4 adjusts the prognunmable amplifier offset. Executing the calibration program 
in the PCL-812 directory, the user must specify the input voltt^e range setting and channel number. Then 
the prognun will guide the setting of the prognuninable lunplifier offset, the A/D offset, and the A/D gain. It 
is imporumt to note that the cidibraiion on one A/D range may cause a small offset on other ranges, so it is 
suggested to calibrate the A/D nuigc for which the best iiccuracy is required. 

G. PCL-830: COUNTER/TIMER CARD 
1. Specifications 

The PCL-830 is a multi-function counter-timer and digital I/O card used primarily in this project 
to generate high-resolution, programmabic-duty-cycle square waves used to drive the Pulse Width 
Modulation (PWM) servos, which move the tiircraft’s throttle and conuol surfaces. It provides ten 
independent 16 bit up/down counters, a 1 MH/. crystal oscillator time base, and 16 bit TTL/DTL compatible 
input and output ports. In the he;ul of the PCL-830 !ue two Advanced Micro Devices AMD9513 System 
Timing Controller (STC) chips used for all counting and timing functions. These STC chips are highly 
versatile :uid adaptable to many real time applications, including 

• Retriggerable digital timing functions 

• Time of day clocking 

• Coincidence aUuins 

• Complex pulse generation 

• Frequency shift keying 

• Event count accumulation 

The STC is addressed by the main processor through two I/O ports: a Contfol port and a Data 
pon. The Control port provides direct ticcoss lo the Status and Command registers, as well as allowing the 
user to update the Dam Pointer register. The Data port is used to provide the data used to communicate with 
all other addres.sable internal locations. The Data Pointer register controls the Data port addressing. Among 
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the registers iiccessible through the Data port tu'e the Master Mode register and five Counter Mode registers, 
one for each counter. The Miister Mode register controls the programmable options that are not controlled 
by the Counter Mode registers. Each of the five general purpose counters is 16 bits long and is independently 
controlled by its Counter Mode register. Through this register, the user can software select one of 16 sources 
as the counter input, a vtu'iety of gating and repetition modes, up or down counting in binary or binary coded 
decimtd (BCD), and active-high or active-low input and output polarities. Associated with each counter are 
a Load register tmd a Hold register, both iiccessible through the Data port. The Load register is used to 
automatically reload the counter to tiny predefined value, thus controlling the effective count period. The 
Hold register is used to save count values without disturbing the count process. 

The PCL-830 requires 6 consecutive bytes of address space, as follows: 


TABLE IIl-lO: PCL-830 I/O Address Map 


Location 

Read Function 

Write Function 

Base Address 

9513 Chip 1 Data In 

9513 Chip 1 Data Out 

Base -t-1 

9513 Chip 1 Command Register 

9513 Chip 1 Status Register 

Base-I-2 

9513 Chip 1 Data In 

9513 Chip 1 Data Out 

Base+ 3 

9513 Chip 1 Command Register 

9513 Chip 1 Status Register 

Btise + 4 

Digitid Output Bits 0 - 7 

Digital Input Bits 0 - 7 

Biise + 5 

Digilid Output Bits 8-15 

Digital Output Bits 8-15 


All ports iue 8 bits (one byte) wide. When loading data that is longer than 8 bits - the digital data 
used to generate PWM signiils tor this project lue 12 bits long ~ the low byte must be loaded first, followed 
immediiitely by the high byte. 


2. Configuration 

The biise addre.ss for the PCL-830 is selected using the first six switches of SWl, located at the 
top of the circuit boiad. These should be set its shown in Table III-l 1. giving an I/O address of Hex 210. 

TABLE lll-ll: Switch Settings for PCL-830 SWl 

























Switches 7 and 8 of SWl control the number of wait states added to the PCL-830. It can be 
configured with zero, two, four, or six wjiit state delays for each transfer of data. Both switches should be 
turned on to select zero delay. There is only one jumper on the PCX-830. This jumper (JPl) should close 
contact 3 to select IRQ3 as the interrupt level. The interrupt is not used in the present configuration, but to 
u.se this interrupt, set the Interrupt Enable (CN1 pin 18) low. The positive edge on the Interrupt Input (CNl 
pin 19) will then generate !ui IRQ level 3. 

Signal connections tire made through one of four 20 pin male connection ports. CNl and CN2, 
found on the slot edge of the card, are used to interface with the AMD9513 STC chips 1 and 2 respectively. 
Figure 111-5 shows the pin idignment for these connectors. For this research, a PCLD-780 wiring terminal 
breakout botad was used to connect signal wires to the ports through ribbon cables. The servos are attached 
by first connecting the red tind black volUige reference wires to +5 V and GND. The white command wires 
iue then connected to OUT 1 through OUT 10. 



It is not necessiuy to insudl iuiy drivers prior to using the PCL-830; however, a counter on the 
AMD9513 must be anned by sending ;m ARM command to the Control port before counting can commence. 
Once armed, the counting process may be further enabled or disabled using the hardware gating options. 
Addilionid commiuids iue provided to step an individual counter by one count, set and clear an output toggle, 
issue a softwtue reset, cleiff luid set special bits in the Master Mode register, and load the Data Pointer register. 


H. Global Pasitioning System (CPS) Receiver 


The Motorola GPS receiver used in this research, model PVT-6, is fully detailed by Twite 
[Twi94], It is a fully automatic position finding system thtit determines and digitally transmits autonomous 
position, altitude, velocity, heading, stilellile backing status, and correct time in three different, user 
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selectable fonnals: Motorola Propriettiry Binary Foniiat, National Marine Electronics Association (NMEA- 
0183) Format, or LORAN Emulation Formal. Ettch of the six parallel channels can find, track, and monitor 
one NAVSTAR satellite. If three satellites with adequate signal strength and bearing spread are available, a 
two-dimensional (latitude and longitude) fix is calculated. If four or more usable satellites are available, 
altitude c:ui iilso be determined. Instantaneous speed and heading is determined by measuring signal doppler 
shifts, although without differential corrections, this information is prone to small errors. 

2. Conriguration 

The GPS receiver mtxiule and its antenna are fully self-contained units that require no special 
configuration. The antenna plugs into the coaxial connector on the receiver module. Power and serial data 
connections tue mtide through a ten pin connector on the back of the unit. A special data cable has been 
mtmufiictured to provide +5 V and GND to pins 2 and 3 respectively. Serial data communications use pins 8 
through 10 and terminate in a DB9 femtile connector. This is, in turn, connected toPCL-744 octopus cable 
number 2. 

I. INERTIAL MEASUREMENI UNIT (IMU) 

1. SpeciTications 

The IMU selected for this project was manufactured by Watson Industries in Eau Claire, WT. 
Model 1MU-600D uses vibrating element sensors to provide the following nine sensor readings: 


TABLE III-12: IMU Data Output 


Sensor 

Scale Limits 

X-Axis Acceleration 

+3g to -3g 

Y-Axis Acceleration 

+3g to -3g 

Z-Axis Acceleration 

+3g to -3g 

X-Axis Anguhu Velocity 

+100 to -100 Degrees/Second 

Y-Axis Anguhu- Velocity 

+100 to -100 Degrees/Second 

Z-Axis Anguhu- Velocity 

+100 to -100 Degrees/Second 

Magnetic Hetiding 

N=7ref, E=c000, S=0000, W=3fff 

Bank Angle 

+60 to -60 degrees 

Pilch Angle 

+60 to -60 degrees 
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Eilch iimtlog sensor rending is processed through a 16 bit A/D converter and the resulting digital 
representation of the signal is in two’s complement format. To use acceleration as an example, 3g = Hex 7fff, 
Og = Hex 0(XX), tmd -3g = Hex 8000. In all, there are nine 2-byte words of sensor data. Each word of data is 
sent as a set of four ASCII chtmicters (0-9 or ABCDEF) corresponding to the hexadecimal representation of 
the 16 bit word. This complete bank ofdataisterminatedby a carriage-return and line feed, bringing the total 
size of one cliiUi reading cycle to 38 bytes. The sensor data is sent continuously at 9600 baud with one start 
bit. one stop bit, tind no parity bit. At this .speed, ignoring any overhead for data formation, a full data bank 
could be received every 31.7 msec, or just over 31.5 Hz. 

The IMU can also receive dtita. The receive line is used for calibration, so care should be taken 
to send only the following signals:. 


TABLE m-13: IMU Input Signals 


Sigmil 

Definition 

1 

Continuously send bank 1 data 
(Data described above) 

R 

Continuously send bank 2 data 

Q 

Exit Initialization 

w 

Re-enter Initialization 


Tlie IMU nonntdly requires 43 minutes to warm-up and initialize. During initialization, the unit should 
not be moved for best accuntcy. The IMU will send out the bank 1 data stream as it is initializing. 

2. Cnnilguratinn 

The IMU is a fully self-cont:iined unit with only one nine pin port for power and serial data connections. 
Table I1I-I4 shows the pin contlgunition. A speciid data cable has been manufactured to provide GNDand 


TABLE 111-14: IMU Pinout 


Pin 

Function 

1 

Power GND 

2 

+28VDC 

3 

Signal GND 

5 

Signal Receive 

9 

Signal Send 
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+28 V power to pins 1 ;md 2 respectively and tenninates with a DB9 male connector. This is, in turn, 
connected to PCL-744 octopus cable number 1. Although the manufocturer attests that the unit can operate 
with its little :is 22 VDC supplied, it must be with respect to system ground for the serial communications to 
have the proper signal levels. Beaiuse of this the +12V to -12V spread available from the system power 
supply cannot be used; a separate power supply was used for test purposes. Maximum power consumption 
is 250 mA at+28 V. 

J. DATALINKS 

Two different datalink.s htive been developed for the UAV so far. Both were commercial off-the-shelf 
(COTS) products that had to meet .sevenU criteriti: 

• Cost limitations 

• Weight limitations 

• Power limitations 

• Size limitations 

• Sttuidard serial interliice 

• Ability to transmit/receive beyond the line-of-sight 

• Frequency agility 

• Hardwtue reliability 

• Adequate d.ita throughput 

The first datalink solution was a X.25 piicket radio tenninal node controller (TNC) connected to a 19.2 
Kbps modem in combination with a UHF wide-band transceiver developed by Reichert [Rei93]. This is a 
robust system that meets or exceeds almost every criteria. Reichert’s estimate of required data throughput is 
accurate in scope, but may change slightly in the final design. For example, he lists the control refresh rale 
as 40 Hz while this controller operates at .32 Hz. He estimates 8 bits per servo update, while the present 
configuration uses 12; however, the present configuration could be reduced to 8 bits per servo with no 
noticeable change in perionmmce. An updated throughput requirement estimate is shown in Figure III-6. 
Using this updated requirement, the ctipticity of this datalink, which yields 19.2 Kbps simplex or 9600 bps 
duplex, is exceeded. Possible solutions would be to reduce the servo input to 8 bits and to refrain from 
downlinking INS tmd non-lNS sensor data for every control cycle. 

The second datalink solution was a direct-sequence spread spectrum UHF datalink as developed by 
Bess [Bes94]. This datalink til.so used a modified X.25 protocol with a top transfer speed of 19.2 Kbps. It 
hits prognunmable length packets and perfonns its own error correction and flow control. Spread spectrum 
ti I IS the added advantages of being less susceptible to jamming signals and may be operated 
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without tut FCC license. The unit includes ti serial data cable that terminates with a DB9 female connector. 
This is, in turn, connected to PCL-744 octopus cable number 3. 


Device 

Controls to be Uplinked 

Refresh Bits per 

Qty Rate Update 

Required 

Throughput 

Throttle 

1 

16 Hz 

12 

192 bps 

Control Vanes 

4 

32 Hz 

12 

1536 bps 

Wing Ailerons 

2 

32 Hz 

12 

768 bps 

Canard Ailerons 

2 

32 Hz 

12 

768 bps 


Servo Positions to be Downlinked 




Refresh 

Bits per 

Required 

Device 

Qty 

Rate 

Update 

Throughput 

Throttle 

1 

16 Hz 

12 

192 bps 

Control Vanes 

4 

32 Hz 

12 

1536 bps 

Wing Ailerons 

2 

32 Hz 

12 

768 bps 

Canard Ailerons 

2 

32 Hz 

12 

768 bps 

Navigation and Sensor Data to be Dowrnlinked 



Refresh 

Bits per 

Required 

Device 

Qty 

Rate 

Update 

Throughput 

GPS Receiver 

1 

1 Hz 

544 

544 bps 

iNS Sensors 

1 

32 Hz 

304 

9728 bps 

Non-INS Sensors 

2 

32 Hz 

12 

1152 bps 

Total Datalink Throughput Requirement 






Required 

Device 




Throughput 

Controls 




3264 bps 

Servo Feedback 




3264 bps 

Sensor Data 




11424 bps 

Estimated Datalink Overhead (15%) 


2693 bps 

Total Datalink Throughput Required 


20645 bps 


Figure III-6: Datalink Throughput Requirements for Ground Control 


The first dtitidink Wits not used in this research because of its complexity and licensing requirements. 
The second dattdink did not perform well in the Uiboratory environment, occasionally locking up or dropping 
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out of service for no appiyent reason. Although configured for 9600 bps throughput, actual results were less 
than hiilf of that. It also required cycling the power iind manual configuration to be restarted. Once 
autonomous flight is achieved, the datalink will diminish in its importance, but as long as direct ground 
control is required, the datalink is the lifeline and the weakest link in controller communications. 

K. ANCILLIARY EQUIPMENT 

In addition to the tiforementioned htudware integral to the conuxtller itself, ancillary equipment was 
necessary to form the complete system. In order to control the UAV, servos and a source of power are 
needed. Any COTS model airplane servo motors could be used, as described by Stoney [Sto93], provided 
they generate sufficient torque to hold the conUol vanes position in the thrust stream. The servos used for 
this UAV were Futaba high torque inixlel FP-S34. The red and black wires connect to +5 V system power 
and system GND respectively. The white command signal wire is attached to the PWM output signal from 
the PCL-830 counter/timer cmd. Tlie white feedback wire connects to one of the A/D analog input channels 
on the PCL-812 lab card. Power for this research project was generated by a standard AMAX 200 W power 
supply that provided up to 20 A at +.S V, 8 A at +12 V, and 0.5 A at both -5 and -12 volts, which was ample 
for till htudwjue used. Power generation ;md storage will vary according to the UAV design. Although not 
investigated in this reseiuch. it is a very technicid problem that affects the operation of all hardware. 

A video graphics adapter (VGA) card linked with a standard VGA monitor and a Microsoft in-port 
mouse, together with the hmd disk tmd floppy drives represented the detachable part of this system hardware 
which was necesstuy for system development only. Once the controller software was developed, it was 
minsfened to the RAM Disk. The .system was then configured to boot from the RAM Disk and automatically 
invoke the controller program. The keyboiffd tind monitor are also detached prior to installation into the 
airfnune; however, the softw.ye must be modified slighUy to accept user commands from the datalink prior 
to operation without the keyboiud and monitor. 

L. CHAPTER SUMMARY 

This cluipter gives a detailed description of the specifications of the hardware selected for the UAV 
controller, iuid the configuration details necessary to enable all equipment to interact together, including those 
subsystems developed by other students. Using this information, system users and follow-on researchers will 
know and understtind how the system was designed to operate tmd the configuration details necessary to 
reconstruct a simihu' system. For additional information about the specifieations or operation of this 
hiudwiue. see Appendix C or the published user’s miinutds. 
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IV. SOFTWARE 


Once the hardware has been selected, it is the software that actually shapes the operation of the 
controller. The hardware tind software have a symbiotic relationship by which neither can function without 
the other. The software must operate within the confines of the hardware’s capabilities and configuration, and 
the h.'irdw.'u-e fulfills its tasks in a coordinated manner by taking its direction from the software. Software 
gives the system its function and its personality. It provides for the interface by which the user comes to know 
and recognize the system, it provides the muisfer and organization of all the data crucial to the controller's 
operation, tuid it coordinates the functions of and sets the cadence for the hardware components. Where 
hiudwiuo is the body, software is the life blood. 

This chiqrter will provide ;ui overview of the scope of the software written for this research. Beginning 
from the original requirements, it will specify the conventions, definitions, and structures necessary to help 
the reader understtmd the code. It will deUtil the software environment in which the software is designed to 
operate. :md it will brietly describe the function of the various procedures. A complete listing of the code is 
included in Appendix A. 

A. OVERVIEW 

The UAV is a multi-faceted project bringing together many varied disciplines. Since the scope of this 
resetirch w:is to design the Retd-Time Executive (RTE) for a central controller, it required the assimilation of 
many sub-systems into one interoperable, cohesive, control system. These sub-systems were developed by 
other students as ptut of an ongoing development effort. Among the many sub-systems previously developed, 
this RTE wiLs specifictilly designed to cixirdinate datalink development by either Bess [Bes94] or Reichert 
[Rei931, navigation system development by Twite [Twi94] and Hallberg [Hal94], servo control development 
by Merz [Mer92] and Monui [Mot93], tuid aeronautical conUol algorithm development begun by Davis 
[Dav92] and Brynestad rBry92], tuid continued more recently by Bolyard (Bol94] and Moats [Moa94]. 

1. Requirements 

As the bttckbone of the UAV conuoller, the RTE designed for this research acts like the conductor 
of ;ui orchestra, directing the How of data and cueing the execution of the various controller functions at the 
correct moment in time. Tile controller's most basic requirement is to provide positive conuiol of the aircraft. 
This includes tmtilyzing the present state, comparing the present state with the desired state, and making the 






necessary adjustments. In order to provide this control, the control software must meet several other criteria 
as well. Specifictilly: 

• The software must be able to receive datti finom all flight sensors (GPS, INS, non-INS). 

• The softwtue must recognize and store a correct and complete data package from each sensor. 

• The software must recognize tmd discard corrupted data packages received from any sensor. 

• The softwtire must ttlways mtiiniain the most recent data available from each sensor. 

• The software must provide Ktilman filtering of navigation data, selecting the most appropriate 
source for use by the control tilgorithm 

• The software must recognize command input and determine desired aircraft posture and 
position. 

• The software must calculate corrections necessary to correct any deviations from desired 
posture and position. 

• TTie software must generate PWM signals for servo motors to effect the necessary corrections. 

• The softwiue must be able to transmit and receive data through the datalink as necessary. 

Other requirements are not as obvious, but beciune apparent during the development of the system. They 
include a predisposition to be written in C language and to be interrupt driven. In addition, the RTE must 
detil effectively with exceptional circumstances, and it must be flexible and clearly written. 

a. The RTE should be written in C language 

Because of the low level prognunming requirements, the project did not fit well with an 
object-oriented pmadigm. In addition. iteronautical engineering students developing the control algorithm are 
using a prognim called Matrix-X which generates modules in C code. To interoperate with these modules, 
and for retisons mentioned in Chapter 11, C was chosen its the programming language. 

b. The RTE should be interrupt driven 

As delineated in Chtipter II, htird real-time systems are required to meet timing deadlines 
imposed by the outside environment or risk system failure. When the control loop is initiated by a timed 
interrupt, it iissures that the system will tilways execute positive control functions at a uniform interval which 
is easily regulitted. This not only frees the processor to do other things when not executing the control loop, 
but also ill lows the conu-ol lixip to interrupt slower (by processor standards) processes, such as generating 
servo commiuid pulses or writing to the screen, prohibiting their occurrence from affecting system timing 


c. The RTE mast deal effectively with exceptional or emergency occurrences 

What if the diitidink fails or the buffers are full? What if the CPU gets into an infinite loop 
or comes to a hiilt? What if the openilor wiuits to reset the system? What if the GPS or IMU do not deliver 
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a complete message? These or any number of other possible mishaps or exceptions can occur, and the system 
must be able to respond appropriately and reestablish positive control of the aircraft. Any problems with 
system integrity come under the auspices of the RTE. 

d. The RTE must be flexible to evolve with the rest of the system 

The development of the UAV was designed in five phases, as outlined by Reichert [Rei93]. 
As the control of the UAV evolves from remote ground control to full automation, the software must be 
flexible enough to evolve with it. To facilitate this requirement, it should be modular in design; each 
procedure should be self-contained and should perform a specific function. 

e. The RTE must be clearly written to facilitate follow on work 

Just as this is not the first research project on the UAV, it will not be the last: however, 
interoperability luid cohesiveness will still be requirements. The software programs are intended to be 
self-explanatory through fonn, logic, iind inserted comments. Where they are not, this research document is 
intended to serve as a programmer's miuiutU for all functions of the software. 

2. Definitions 

All preprocessor directives, including compiler token definitions, global variable definitions, and 
procedure prototypes are contiuned in the lone header file called DEFS.h. An index of all other variable 
munes is contained in Appendix B, which may be used as a glossary by subsequent programmers. Special 
complex variables are stored in C structure.s, as described below. 

a. Structures 

Very few su-uciures are used in the control software, as the necessary data types are not 
complicated. The first is struct T_GPS. inuoduced by Twite |Twi94] and fully defined in the header file 
GPSTRUCT.h. This structure is globally mainuuned and gives access to all possible information obtained 
from the GPS receiver by simple structure-member reference. For example, the control algorithm could 
access the degrees of hititude of the present position by simply using the variable name 
gps.pcs.latitudc.degrees. 

Tlie second is ti PANDL. which represents a pointer and its length. This is the preferred 
methtxlof ptissing dam eonrained in buffers of differing length. It allows one structure argument to be passed 
<md yet tdlow the .stune prixtedure to htindle the various length buffers consistently. 
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3. Conventions 


As a meiins ot standiirJization. a set of conventions have been established in the design of the 
control softwtire. Any procedures not piirt of the RTE, but subsequently added to the controller software 
(hereafter termed participating procedures) should conform to these conventions. In order to avoid 
contention tmd interference, the RTE must maintain control over several critical parameters, including 
execution timing, data mrnsfer, memory allocation, and the operation of the hardware, particularly the 
datalink. 

a. The RTE must maintain control over all timing 

This is the defined function of the RTE. yet for it to be effective, participating procedures 
should be of relatively constant execution time. Recursion and loops must be used carefully, and the 
participating procedure should not ctill another procedure that should be under the control of the RTE. The 
challenge of programming the RTE is then reduced to a complex scheduling problem among a relatively 
small number of processes which ;dl have concise scope and operating parameters. 

b. The RTE must maintain control over all data 

As a corollary to the previous requirement, the RTE also maintains control over all aspects 
of data stonige ;uid transfer. This includes I/O port number definitions, flow control definitions, and actual 
I/O requests including input from the keybotird, output to the screen, or data transfers with the datalink. This 
is crucial to mainuiin coordintited operation of all controller functions. Any participating procedures must 
refrain from making their own data tninsfer calls, unless it is the express function of that procedure. Data 
infonnation placed in a buffer is pas.sed using the PANDL structure defined above. 

c. The RTE must maintain control over memory allocation 

In the course of operation, a given procedure may be called many times by the RTE. Memory 
allocation is a relatively slow procedure, and should be minimized and carefully managed. Any procedures 
that allocate memory must cleiu that memory prior to return to the calling program. It is preferred to have 
the RTE allocate the memory luid then pass that PANDL to the participating procedure fill the buffer and 
modify the length. 

d. The RTE must maintain control over the hardware 

It is the funciion of the RTE to direct the execution of the hardware. Unless it is their defined 
purpose, piuticipaling procedures should not send signals to hiudware or in any manner change the operating 
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piiraineters of the hardware established by the RTE. This will preclude the RTE from coming into contention 
with the operation of one of the participating procedures. 

e. Messages coming from the ground must have a set format 

Because the dtmdink was only used to transmit information down to the ground in this 
research, this fonniit has not been completely esUiblished. The read_datalink() procedure is written to expect 
a special chiuacter to denote the suut of the message (presently using followed by a two byte integer 
representing the length of the message in bytes, followed by the message itself. It is possible to also include 
a one byte tiction code after the message length to help the RTE determine what action to take with the 
incoming message. Participating procedures that uplink information to the RTE must follow this convention 
for the inessiige to be properly deciphered. 

B. COMPILER CONFIGURATION 

The softwme wtis developed under Borland C/C++, version 2.0. Invoking this program using the 
command BC, without any flags, brings the user into an integrated development environment (IDE). The 
IDE, otherwise known ;is the Programmer's Platform, includes a multi-ftle editor, multiple overlapping 
windows, tut integrated debugger, a built in assembler, and support for in-line assembly of other object 
mtxlules. Pull down menu selections <ire at the tup of the screen, and most are similar to other graphical user 
interfaces. The following compiler configuration parameters are important to ensure that the code will 
compile properly. 

I. Project File 

Using the Project pull down menu gives access to the project file. The project files are kept in the 
C:\borl;uidc\bin directory and perform two important functions. First, the status of the screen (or desktop) 
and idl preferences selected, including compiler options, are stored in the project file. Then, when the project 
is opened, the screen and all preferences ;u-e automatically returned to the settings selected for that project. 
Second, the project conttiiiis a lisl of files to he compiled at run time. This allows the user to specify other 
file.s, like header files or .sepmate objecl modules, to be included in the compilation. As shown in Figure fV-l, 
two .such files tae required for correct compilation of the controller software. 812CL.lib is an object code 
libriuy for the intrinsic functions u.sed to operate the PCL-812 board. MOXA-CL.obj is an object code 
module for the intrinsic functions used to access the PCL-744 board. According to the manufacturer, both 
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boiirds require that the intrinsic functions be used to access the boards. Experience has confirmed that the 
intrinsic functions are also the easiest and most efficient method of accessing the functions of these boards. 



Project: Monitor 




File Name 

Location 

Line 

Code 

Data 

Monitor.c 

..\..\Control 

946 

14788 

4209 

812CL.Iib 

..\,.\PCL-812\C 

n/a 

n/a 

n/a 

MOXA-CL.obj 

..\..\PCLS-802\LIB\C 

n/a 

n/a 

n/a 


Figure IV-1: Compiler Project Screen 


2. Compiler Options 

The Options pull-down menu gives access to the selected compiler options. Most of these may 
be set to the user’s preference, but sevenil are important and should not be changed. Under Code Generation, 
the huge memory model should be selected and Automatic Far Data should be checked. Because of the 
“segment;offset” addressing scheme in the computer, several memory models are available. For each item 
of code or data, the compiler can either generate explicit segment and offset addresses or can use the offset 
alone within a default segment address. The hu-ge model generates explicit segment and offset addresses for 
fdl diita items, thus allowing iui unlimited amount of code find data with only one constraint: no single data 
item can exceed 64 Kbytes [BarXy|. Tliis model is shown graphically in Figure IV-2, and is necessary for 
direct memory access :md fur sciting i:ir pointers used in the interrupt service routines (ISRs). 

In the EntrylExit Code Generation menu, neither Standard Stack Frame or Test Stack Overflow 
should be checked. Because of the heavy use of the stack for ISRs and console functions, like printing to the 
screen, the stack frame should be as large its possible. Additionally, with the Standard Stack Frame option 
turned off, iuiy function that does not use locid variables and has no parameters is compiled with abbreviated 
entry ;uid return codes. Tliis makes the resulting aide shorter tuid faster. The Test Stack Overflow generates 
code to check for .slack overllow at run lime. This code is not necessary, and can cause run-time problems in 
the controller. Similtaly. under the Linker option, no stack warning should be checked. During interrupts, 
the suick is not where the stack checker expects it to be. Under Optimization options, select optimize for 
speed. Under normal conditions, the compiler will choose to optimize for size, choosing the smallest code 
sequence possible. With this item toggled, the compiler will choose the fastest sequence for each task. This 
is iinporttmt since the prognun does not come close to exceeding the 2.88 Mbytes available on the RAM Disk, 
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but is significantly time-constrained. Last, under Directories, the compiler is operating with the Include 
directory set to CiNborlandcNinclude, the Library directory set to C:''borlandc\lib, and the Output directory set 



C. SYSTEM INITIALIZATION 

This section highlights initializations that must be completed before the program can start the flight 
maniigeineni unit (FMU) sequence to control the UAV. For proper operation, the software program must 
have been compiled in accordtuico with the compiler options described above. Then, once the program is 
invokeil, the inainO prtx;edure i.s the first code to execute. 















1. Software Initialization 


In the beginning of the mtiinO procedure, special exit handling routines are set up. The atexitQ 
procedure directs the prognun to execute the shut_down() procedure whenever the program is terminating 
from any retison. This is a handy function because the termination point can come anywhere, yet the 
shut_down() procedure will always be executed, assuring that the ISR vectors have been returned to normal, 
the allocated memory has been freed, ;ind the I/O ports have been properly closed. 

The ctrlbrkO procedure establishes a return point in the program in the event of a control-break 
key sequence. It can be seen in the bretik_hiuidler() routine that this is a method for completely restarting the 
prognun without having to reboot. After the exit handling routines are set up, the global structures needed to 
hold .sensor data me allocated. This includes a struct T_GPS, PANDLs for the IMU and GPS information, 
and data and param arrays for the PCL-812. 

2. Hardware Initialization 

After establishing exception handlers and memory allocation, the main program calls 
inilialize_hwO . This procedure controls the ptuameters of the hardware that must be set up in software, 
which is necesstuy for three of the hiu-dw:u e ctuds; the PCL-812 Lab Card, the PCL-744 Serial I/O Card, and 
the PCL-830 Timer/Counter Cmd. 

a. PCL-812 

The PCL-812 relies solely on the param array for information concerning its operation. It is 
importtint ihtu the hmdware :md software configurations match. Specifically, paiam[4], IRQ level, must 
match the setting of jumper JP4; pmaml?], trigger level, must match the setting of jumper JPl; and 
ptuuinl 17], gain cixle, must match the setting of jumper JPD. Other important parameters are param[S] and 
panun[6]. the product of which divides the 2 MHz clock to determine the speed of the internal trigger, and 
pturunj 14], [ 15], tuid [16] thiit set how mtuiy A/D conversions will be done and on which analog inputs. With 
the ptaam turay esiablished, the iniliiilize_hw() procedure calls PCL-812 function 3 to initialize the hardware 
and PCL-812 function 4 to begin A/D conversions. 

b. PCL-744 

Tlic PCL-744 uses the same library of softwtne functions as the PCLS-802 Serial I/O Card, 
wliich is not used in this project. The PCLS-X02 softwttre hits three major parts: first is the complete RS-232 
biLsed softwme device driver for I/O proces.sing ttnd control; next are the interface libraries which allow the 
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use of high-level programming liinguages to control serial communications; and third are application 
programs which iillow troubleshooting of the serial communications. All of these interface library procedures 
begin with "sio_” and so are hereafter tenned sio functions. Advantech engineers have confirmed that the use 
of these libnuy functions is the only method available for accessing the PCL-744. These sio functions are 
fully described in Chapter 3 of the PCLS-802 PC-ComLIB Manual by Advantech. The initialize_hwO 
procedure uses these sio functions to configure each of the eight serial ports as follows: 

• 9600 baud rate 

• 8 data bits 

• 1 stop bit 

• No parity 

• DTRoff 

• RTS off 

• Hardware flow control off 

• Software flow control off 

Compiler variables for the bit conligunilions needed for these settings are found in HEAD-C.h. Companion 
sio functions ;ire used in check_h<'irdwiue() to read the values set for each port After configuring the ports, 
initialize_hw() opens etich port, flushes the receive <md transmit buffers, and sends initialization codes to the 
GPS receiver and the IMU. 

c. PCL-830 

The last section of initL'ilize_hw() initializes the PCL-830 card. The original software was 
written by Monui [Mor93] for another circuit card that also used AMD9513 System Timing Controller (STC) 
cliips. :md .so it could be ported over with minor modifications. This code is well documented by Merz 
[Mer921. Each timer is configured as follows: 

• Counter clock source set to F1 (1 MHz) 

• 8 bit wide daui bus (mandatory for the PCL-830) 

• Bintuy counting on ftilling edge, counting down repetitively 

• Reload counter from Load or Hold register 

• Disabled daui pointer increment (this is conttolled by for-loops in software) 

• No gating conttol 

• Output control set to toggle on terminal count 

This configuration is equivalent to ti specittl ized version of the AMD9513 Mode F. Under this configuration, 
the individutil counter is tdlernatively loaded from its Loiid and Hold registers. First, the counter loads the 
viiiuc from its Hold register tutd puts the output high (5 V) upon terminal count (counting down to zero). Then 
the counter hauls the vtiiue from its Load register tmd toggles the output low (0 V) upon terminal count. The 
vitlue in tlie Load register cretites the desired length of the PWM pulse, which should be between 0.6 ms and 
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2.4 ms. The sum of the Loiid and Hold registers sets the PWM signal refresh rate, which should not exceed 
10 ins (Dav92J. Noutbly, this inode differs from Mode C in that the counters are not required to be loaded 
and <u-ined intuiually, except initially. This initial arming is done at the end of iiiitialize_hw(). 

D. INTERRUPTS 

Interrupts ciui come from two different sources: hardware and software. Both hardware and software 
interrupts iue decoded by hiu-dware chips called Peripheral Interrupt Controllers (PICs), and both use the 
interrupt vector table to find the location of the interrupt service routine (ISR), a small program designed to 
address the cause of the interrupt. Htu-dwtue interrupts typically call the processor's attention to an external 
event, such as a key stroke or other asynchronous action. Conversely, software interrupts are like 
inshuctions; they are part of, tind therefore synchronous with, the running program. 

The lowest 1 Kbytes of memory is allocated for an interrupt table that can store the four byte 
“segment:offset’’ address for etich of 256 ISRs. The correct ISR is located by its number, no matter where it 
is located in memory. The CPU simply has to multiply the interrupt number by 4 (since each segment has 
four bytes) turd jump to the address it finds at the resulting offset in segment 0. For example, the address of 
the ISR th;u serves interrupt 70 is found in segment 0 at an offset of 70 X 4 = 280 = 118h. The interrupt table 
does not contain the ISR code itself, but the address of the beginning of the ISR code. To change the 
execution of :m ISR, it is only necessary to change the address in the interrupt table for the desired interrupt. 
Upon occurrence of an interrupt, the CPU will place the value of the program counter and all internal registers 
on the st.a-k for future reference. Then it will look up and jump to the address of the ISR. Upon completing 
execution of the ISR, the CPU then relieves the infonnation it had placed on the stack and resumes normal 
operation [NorK.SI. 

The PIC is the chip th:it uruislates extemtU interrupt request signals (IRQs) into hardware interrupts, 
allowing externtil devices to generate interrupts. The microprocessor itself has only two interrupt lines: one 
for mtiskable interrupts imd one for non-maskable interrupts. Maskable interrupts are those that can be 
disabled or enabled in softwtire. The PIC assigns priorities to its eight interrupt lines, with line 0 programmed 
for the highest priority by default. When one of the lines is activated, the PIC blocks all IRQs of equal or 
lower priority. It continues to block the,se IRQs until it receives an end-of-interrupt (EOI) code from the 
prixte.ssor. The pixKessor communicates with the PIC at the microcode level. When its maskable interrupt 
line goes high :uid interrupts tue entibled. it queries the PIC which is the highest pending IRQ and then jumps 
to the iLssixtitUed interrupt vector. The CPU ctud has two 8259A PICs. The output line of the secondary PIC 
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is attached to IRQ 2 of the priititiry PIC, tind the output line of the primary PIC is connected to the processor. 
This allows 16 different IRQ signals to be recognized by the processor. When IRQ 8 or higher is generated, 
the processor queries the PlCs and finds IRQ 0 through IRQ 7 of the secondary PIC is cascaded through IRQ 
2 of the primary PIC [Rie93]. 

1. (jenerating Software Interrupts 

As discussed in Chtipter II, the ctidence of the entire control loop is built around the periodic 
occurrence of a software interrupt. Because the CPU will immediately jump to the ISR when interrupted, 
placing the beginning address of the control loop program in the interrupt table, and generating a periodic 
interrupt to jump there, wiU gutirtuilee a consistent frequency of control loop execution. For the UAV, the 
entity that executes the control loop is ctdled the Flight Management Unit (FMU). Within the start_fmu() 
procedure, the ISR for the RTC interrupt (70h) is replaced with a pointer to the control loop procedure 
new_vectorO. Suu1_fmu() then proceeds to generate a periodic interrupt, as described below. 

Every computer h;is some version of a Programmable Interval Timer (PIT). Intel 80X86 
processors usuiilly use a 8253 or 8254 PIT that has three independently programmable 16 bit counters that 
c:ui be configured in any of six counter modes. On the CPU card, one of these counters is used to periodically 
refre.sh the DRAM; one is used to genonue tones for the speaker. The third timer is used to generate an 
interrupt 8 (IRQ 0) at 18.2 Hz used to tidjusi the current time and date in the system BIOS area. It seemed 
like a simple process to chtuige the frequency of this interrupt and "hook” it for the FMU; however, this led 
to problems. Because IRQ!) is the highest priority, all other computer functions, such as serial 
communications, disk operations, ;uid keyboard activations, were all blocked out by the PICs. In addition, 
some ptuts of MS-DOS that require periodic service hook this interrupt, and these functions could be 
tidversely affected by changing the frequency of the interrupt. Most significantly, the engineers at Advantech 
confinned thtit the 8254 functions on the CPU ctud are part of an "integrated chip set” and could not be 
accessed independently. For these reasons, tuiother timer had to be used. A timer on the PCL-830 could be 
used, but this w:is discounted because it was on another ctud tmd would generate urmecessary data traffic on 
the btickpltme bus. Fortunately, there is another timer available on the CPU card that generates interrupts - 
one ihiU is not widely documented, but is ttvailtible on the htudware. It is called the Real-Time Clock. 





2. The Real-Time Clock 


The reiil-time clock (RTC) is piirt of the Motorola MC146818A CMOS chip shared by the system 
BIOS. As comptired to the 8254 PIT, it has several disadvantages; 

• The RTC is less flexible: it handles only 15 possible interrupt frequencies between 2 Hz and 
32767 Hz. 

• The default ISR switches off the RTC interrupt after a time-out expires. 

• The RTC and IRQ 8 tae not well documented. Most of this information was gleaned from 
online sources from the Internet. 

Still, the RTC is perfect for this resetuch application because it avoids all of the prcAtlems listed 
above for the 8254 chip: 

• The RTC allows the higher priority keyboard and I/O interrupts to proceed normally. 

• The RTC is not polluted with side effects. 

• The RTC is available for use on the hardware being used. 

Because the RTC exists outside of the normal address space, it cannot contain directly executable 
code. It is communicated with through I/O ports 70h and 71h. Port 70h is the index register and pwt 71h is 
the data register, as defined in DEFS.h. All internal registers of the RTC are accessed by seaing an index at 
port 70h tmd reading from or writing lo port 71h. The output from the RTC is in hexadecimal. Figure IV-3 
dettiils the CMOS memory allocation. The ten clock data registers are not used in this research, although it 
is envisioned that the system clock will be updated from the GPS time data in the future. In order to use the 
RTC to generate periodic interrupts, only the four status registers are used. 

There are a few caveats when programming the RTC. First, the data register must always be read 
from or written lo after writing to the index register. Also, there should not be a long delay between writing 
to the index register and residing from or writing to the data register. Waiting too long between the two 
operalions can cause a maliVnction of theCMOS chip [Dun86]. Interrupts must be disabled while 
programming the RTC. T(ie non-m.iskiihle i^rrupt (NMI) must also be disabled. Since the chip is 
non-volatile, it continues to^work even in the event Of a system reboot caused by a NMI. The system reads 
vital piutuneters from the ch^, such as memory size and configuration. Malfunction of the RTC chip is to be 
avoided at <UI costs. Therefore, it is safest to toggle the NMI off by toggling bit 7 of the index register when 
selecting the status regi.ster to use. The following describes how the status registers are utilized. 





The first 14 bytes of the MC146818 chip consist of ten read/write data registers 
and four status registers, two which are read/write and two which are read only. 

The format of the 10 data 

registers is: 

OOh 

Seconds 

(BCD 00-59, Hex 00-3B) Note: Bit 7 is read only 

Olh 

Second Alarm 

(BCD 00-59, Hex 00-3B) 

02h 

Minutes 

(BCD 00-59, Hex 00-3B) 

03h 

Minute Alarm 

(RCD 00-59, Hex 00-3B) 

04h 

Hours 

(24 Hr. Mode: BCD 00-23, Hex 00-17) 

(12 Hr. AM; BCD 01-12, Hex 01-0C) 

(12 Hr. PM: BCD 81-92, Hex 81-8C) 

05h 

Hour Alarm 

(Same as Hours, above) 

06h 

Day of Week 

(01-07, Sunday = 01) 

(BCD 01-31, Hex 01-IF) 

07h 

Date of Month 

08h 

Month 

(BCD 01-12, Hex 01-1C) 

09h 

Year 

(BCD 00-99, Hex 00-63) 

The fgrrnat of the tour status registers is: 

OAh 

Status Register A {read/write) 


BH 7 (Read Only) 
Bits 6, 5, 4 

1 = update cycle in progress, data undefined 

22 stage divider of 32.768 KHz time base 


Bits 3 - 0 

Rate selection bits for interrupt 

OBh 

Status Register B (read/write) 


Bit 7 

Cycle update: 0 = disabled, 1 = enabled 


Bite 

Periodic interrupt; 0 = disabled, 1 = enabled 


Bits 

Alarm interrupt: 0 = disabled, 1 = enabled 


Bit 4 

Update-ended interrupt: 0 = disabled, 1 = enabled 


Bits 

Square wave output; 0 = disabled, 1 = enabled 


Bit 2 

Clock data mode; 0 = BCD, 1 = Binary 


Bit 1 

24/12 Hour Selection: 0 = 12,1 = 24 


BitO 

Daylight Savings Time: 0 = disabled, 1 = enabled 

OCh 

Status Register C (read only) 


Bit 7 

Interrupt request flag; 1 if any of bits 6 - 4 are 1 and 
appropriate enables in Reg. B set to 1. Generates IRQ8. 


Bite 

Periodic interrupt flag 


Bits 

Alarm interrupt flag 


Bit 4 

Update-ended interrupt flag 


Bits 3 - 0 

Not Used 

ODh 

Status Register D (read only) 


Bit 7 

Valid RAM; 0 = dead battery or disconnected, 1 = good 


Bits 6 - 0 

Not Used 


Figure IV-3: Organization of CMOS Memory 








SUitus register A is used to select an interrupt rate. The basic oscillator &equency is 32,768 Hz, 
set in bits 4 - 6. The lower four bits (0 - 3) of status register A select a divider for this oscillator. The resuldng 
frequency is used to generate an interrupt 70h, or IRQ 8. The system initializes these bits to 0110 binary, 
which selects a 1,024 Hz frequency iiccording to the following formula: 

InU'rruplFri-quem y = OscillalorFrequency » (rale- i) 


which ciui be simplified its 


Table IV-1 lists the subset of interrupt frequencies likely to be used for the UAV controller. These 
frequencies lae generated when the corresponding rate is specified in DEFS.h. Presently, the controller is 
executing a 32 Hz control cycle. The fastest frequency possible is 8 KHz using a rate of 3. When using a rate 
of either 2 or 1, the counter rolls over, resulting in the stune frequencies as rates 9 and 8 respectively. 


TABLE IV-1: CMOS Interrupt Frequencies 


Rate 

Frequency 

lO(OAh) 

64 Hz 

11 (OBh) 

32 Hz 

12 (OCh) 

16 Hz 

13 (ODh) 

8 Hz 

14 (OEh) 

4 Hz 

15 (OFh) 

2 Hz 


Status register B contains a number of flags. To enable the chip to generate periodic interrupts, 
bit 6 must be set. Smtus register C is retid only and also contains a number of flags. When several interrupts 
of the RTC tire connected to IRQ 8, these flags make it possible to detect which interrupt caused the IRQ 8: 
periodic interrupt, ahum interrupt, or update ended interrupt. Lastly, the PIC status register must be 
unmasked. Each PIC hits tut 8 bil mask that disables selected IRQs. The American Megatrands BIOS 
disables IRQ 8 at sautup. By clearing bil 0 of the .secondtuy (slave) PIC, IRQ 8 is enabled. 

These actions generate a peritxlic interrupt, but only a single one. Unless status register C is read, 
IRQ 8 will not be generated again. This nieiuis sUitus register C is read inside the ISR, even though its content 
is not importtuit for this application. The PlCs also come into play here. Since the PIC blocks all IRQs of 
equal or lower priority upon the occurrence of an interrupt, the next periodic interrupt cannot be generated 
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until the PICs receive tin enU-of-imerrupi (EOI) code from the processor. This is accomplished by directly 
oulporting tm EOI (value of 20h) to I/O addresses 20h and AOh, the addresses of the master and slave PICs 
respectively. These repetitive actions must be done on every occurrence of the periodic interrupt and so are 
accomplished inside the ISR in a subroutine cidled resetJntQ. 

Common practice when writing ISRs is to jump to the old ISR after executing the new one, but 
because the old ISR halts the periodic interrupt, this method was not used. Without the old ISR, some 
interrupt 15h BIOS functions will fail; however this did not manifest any problems in the present 
conligunition. If necessary to alleviate tliis in the future, store at address 0040:009b a double word value that 
is at least 976 futd jump to the old ISR. The default ISR subtracts 976 from the value at that address and halts 
the RTC periodic interrupt if the re.sult is less than zero. 976 is derived as the number of microseconds that 
elapse between two invocations of interrupt 70h if the RTC is counting at its default ftequency of 1024 Hz. 
The default ISR also issues an mterrupt 4Ah when timed out [Bro92]. 

In addition to resetting the interrupts, the ISR, new_vector(), also increments a count of the 
number of cycles luid cidls the actuid control loop procedure, execute_cycle(). It is within this control cycle 
that idi of the I/O and tiight control operations lakes place. 

E. THE CONTROL CYCLE 

The control cycle is embodied in the execute_cycle() procedure. It is called by new_vector() upon each 
occurrence of the periodic interrupt. During the control cycle, the connuller first retrieves the information it 
needs to determine the state of the mrcnd't by invoking each of four I/O device drivers; next, it calculates any 
corrective actions necessary in the flight_conu-ol() procedure; and finally, it generates the PWM signals 
neces.sary lor the servo motors to effect those correaive actions in the cmd_to_servos() procedure. It is 
important to note that not all of these prtKedures are called during each cycle. Using modulo division of the 
cycle count, it is possible to regulate the interval and period of the various functions. The objective is to keep 
the task load for each control cycle relatively sleiidy. The actual timing of these functions is dependent on 
the frequency of the interrupt. For cxmnpic. the IMU is read every fourth cycle for control purposes, but is 
only downlinked to tlie ground twice each second. This prognunming strategy keeps the RTE flexible and 
the timing pariuneiers easily modified. E;ich of these functions will be examined in detail. 

I. Vt) Device Drivers 

Four I/O device drivers exist within execute_cycle() to take care of the data transfer and storage 
from the four primtu-y sources of d;ita for the FMU. They tue read_imu(), read_gps0. read_atodO, and 
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xmit_to_gnd(). Each of these procedures reads one complete data message from their appointed interface and 
pliu:es that messtige in a pre-established global data buffer. 

As described in Cluipter III, the complete data message from the IMU is 38 bytes long and 
terminates with a carriage return. The global buffer, imu_buf->ptr, has 100 bytes allocated in the main 
program. Because of this buffer restfiction, read_imu() reads the length of the queue and truncates it to 100 
bytes. It then determines if the data in the receive buffer constitutes a partial or full message. If a partial 
mes.sage exists, it reads it away before retiding in the next full message. Last, it confirms whether the message 
reiul Wits a complete 38 byte ine,ssage and sets a fiag accordingly. 

Read_gps() works much the .siune way, except that a full position message is 68 bytes and 
terminiues with a carriage return and a line feed. A 500 byte buffer is allocated in main(). This procedure 
pares down the receive buffer until the buffer size constitutes at least one full message and at most one full 
message plus a partial inesstige. If a partial message exists, it reads it away and then reads in the next full 
message. It also confirms whether the message read was a complete 68 byte message and sets a flag 
d fcly. 

Tlie A/D process on the PCL-812 ciud was inititiled in the initialize_hw() procedure. To read the 
data genenited into the data array, read_iitod() needs only to call PCL-812 function 5, and the data is read in 
automatically. Since the data received is a 12 bit digital conversion scalar value, determining the actual 
ruialog voltages requires a calculation simihu to that done in the show_air_data0 procedure. 

Depending on the mission :md the mode of flight, varying amounts of data will be required to be 
transmuted to. tmd received from, the ground station through the datalink. This data transfer is done by the 
re:id_datalink() and xmiMo_gnd() priKcdures. Retid_datalink() was written for functional completeness, but 
is not utilized in this resciueh. Bitscd on the l.ust convention in Section A.3 of this chapter, read.datalinkO 
will look for the beginning-of-me.ssage cliitmcter, then read the message length, convert the length to an 
integer, iind use the length given to re.id in the appropriate number of bytes constituting the message. If a 
mes.siige is retid, it is stored in the global buffer dl_buf, and a flag is set accordingly. 

The xmit_to_gnd() pnx:edure has the iidvantage that the length of the message to be transmitted 
is known from the PANDL piissed in. The procedure uses the sio_putb function to transfer the data to the 
d;U:iliiik's tran.smit bullcr. Ex|)erunemaiion has shown that the sio_write function works equivalently well. 
The only exception thiU must be considered is a full tninsmit buffer. This situation should never occur under 
nonnal operating circumsliinces; however, in the event that it does occur, the buffer is flushed under the 
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assumption that the data presently attempting to be sent is the most recent and therefore more valuable than 
the old dtiui that wtis clogging the buffer. 

2. Flight Control 

Now that the controller h:is all the information it needs from the various I/O drivers, all that 
remains is to ctUculate the control inputs necessary to fly the airplane and move the servo motors 
appropriately. The flight_control() procedure in this research is only a placeholder for the control algorithm 
module being developed in the Aerontuitictil Engineering Department Eventually, this procedure will 
provide the KtUinan filtering options for choosing the appropriate navigation data from what is available and, 
using this data, will ctdculate integer conuol commands for the throttle and for each of the standard 
three-dimensiotiid control surfaces: tiileron, elevator, and rudder. These control surface commands are then 
passed to the cmd_to_servos() procedure, which translates the three-dimensional control surface commands 
into individual v:me commiuids. The integer command expected by cmd_to_servosO presently represents the 
number of degrees of deflection, but it could be changed to any agreed upon standard between flight_control 
tmd cmd_to_servos. Cmd_to_servos() then sends the appropriate signals to the PCX-830 to generate the 
precLse PWM signtU needed by e;ich vtme servo. This concludes the control loop segment of the program and 
meets all of the requirements for positive control outlined above. The RTE now returns to the point of 
execution prior to being interrupted iind continues its normal activity until the occurrence of the next periodic 
interrupt. 

F. USER SERVICES 

When not executing the control loop, the computer is primarily available for user-oriented services. 
These services include a giitnut of small prtx;edures designed to interact with the system user and provide 
informalioti. Because the systetn runs on interrupts, the control loop described above appears to be running 
in the background, while these user services utilize the screen and keyboard and appear to run in the 
lorcgrottttd. 1 he inilhil and pritnary interface with the user is the menuQ procedure. Menu() presents a 
cointnaiid litie, protnpling for user input. A new user mtiy respond with a question mark, which yields a menu 
of possible choices, tus shown in Figure IV-4. The first three choices, check hardware, start flight 
tntuiagetnent unit, and quit flight tnatiagetnetit unit, have been described above. The remaining choices are 


described below. 





Archytas Monitor Program 
Command ('?'for help): ? 

The following are valid commands: 


(c) heck hardware 

(s) tar1 flight management unit 

(q) uit flight management unit 
(f)light data menu 
(m)emory contents display 

(r) egister contents display 
(i)nterrupt vector display 

(d) os command 

(t) erminate program 

Command (‘?' for help):_ 


Figure IV-4: Main Menu Screen 

ChoosingyZi^/ir dam menu invokes the show_flighl_dala() procedure, which presents a secondary menu 
as shown in Figure IV-5. Tliis menu enables the user to inspect and verify the contents of the global buffers 
containing the flight datii giithered during the control loop from each of the I/O device drivers. This includes 
ASCII representations of the untnuislated GPS message and the output from the IMU, the hexadecimal values 
and corresponding voltages of all A/D tinjilog sources, and the present positions of all servos. These values 
represent the instantaneous buffer contents tu the moment in time they are retrieved. If the FMU is running, 
the buffer conlenls may ehiuige immediately after being read. 


Display which data? 

(g)p5 position 
(l)mu data 
(a)ir data 

(s)ervo positions 

Choice: _ 

Figure lV-5: Flight Data Menu Screen 

The memory contems display, register conlenls display, and interrupt vector display main menu choices 
enable the user to inspect the eontenls of any block of memory, the contents of all storage and segment 
registers of the processor, and the ISR address stored in the interrupt table for any given interrupt respectively. 
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Similiir to the utility of a debugger, these procedures were used primarily during the development of this 
program and sue included for future debugging needs. When programming at such a low level, interacting 
with individutil memory loattions and I/O ports, it is often necessary to have the utility of these procedures. 

Liistly, the Uos command menu choice invokes an MS-DOS shell that the user can work in while the 
FMO is still running. All basic DOS functions, such as copying fdes, directory listings, and invoking smali 
programs tire tivailable, as long its the intended ttisk does not require BIOS interrupts 81h or 83h. Terminating 
the program will iilso yield <1 DOS prompt, but only after the program completes its shutdown sequence. 

One other seconditry menu is available to the user, tdthough it is not listed in the main menu. It is 
invoked by the Clrl-Break or Ctii-C key sequence. Both of these are standard key sequences used when the 
user wants to terminate what is executing. In this case, the bteak_handler() procedure is invokes and a menu 
similiu- to Figure lV-6 is displayed. 


Why did you break? 

(c)old reboot machine 
(w)arm reboot machine 
(r)estart program (reinitialize hardware) 
(g)o back to main menu 
(t)erminate program 

Choice:_ 


Figure IV-(i: Break Handler Menu Screen 

The most drtcslic response to this prompt is a cold bool. This is similar to the system initialization done 
when first powering up the computer, including all diagnostic .and memory checking sequences. A warm boot 
is simihu to the Ctrl-Alt-Del key .sequence and causes the computer to reboot without the diagnostic and 
memory checking sequences. This mtikes it slightly faster and less disruptive than a cold boot. Both of these 
options invoke the bootsPiipO pnx;edure, ptLssing in the chosen parameter of cold or warm. Because disk 
ciiching is used. hoolstntpO first Hushes the citches to insure that no information is lost and reboots the 
computer. If the computer is operating correctly, the user may elect to re-initialize only the controller 
hiudwiue This restart program option csiuses the computer to execute the hardware shutdown sequence and 
then shut the program again from just sifter the buffer tillocalion in main(). Other choices allow the user to 
return to the main menu or tennintite the program. 
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U. CHAI'TER SUMMARY 


This chapter gives a deliiiled description of the software program written to function as the control 
softwiire for the UAV. The reader should understand the full scope of the endeavor, including the 
requirements and guidelines under which it was written, and the interoperability with the hardware, including 
those sub-systems developed previously by other students. This chapter serves as a programmer’s manual, 
to tiid the understiinding of the code shown in Appendix A, as well as to set conventions and guidelines for 
sub.sequenl cixle to follow from other work on the UAV project. The operation of the Real-Time Clock chip, 
in piuticuku-, is not documented elsewhere, iind is therefore completely detailed in this chapter. 






V. CONCLUSIONS 


The g«il of this resetirch wils to cresite a functional central controller for an UAV. This controller is 
envisioned to integrate various subsystems designed by other students as part of an overall, interdisciplinary 
development project. It represents the airhome h:Uf of a full UAV control system that is planned to evolve 
from remote ground controlled flight to fully autonomous flight in five phases of development [Rei93]. 

A. ACCOMPLISHMENTS 

From the general go:d to create :ui UAV controller, specific operational requirements were derived. 
From these operational requirements, system hardware was selected and design parameters were codified. In 
the course of tlie design and syntliesis of the controller, several significant milestones were achieved: 

• The system htffdwtu-e was ;is,sembled and configured for proper operation. 

• A method for generating periodic interrupts was determined and successfully implemented. 

• Multi-path serial I/O was achieved using the PCL-744 card. 

• Daudink subsystems were successfully integrated. 

• Air dtita and navigtuion subsystems were successfully integrated. 

• Servo control subsystems were successfully integrated. 

• The RTE was designed tuid implemented to interrelate and coordinate all subsystems. 

• Communication <uid prognunming standards were developed. 

• Fault tolerant provisions were made to bolster system reliability. 

• User interfaces were designed and implemented. 

The UAV controller wits designed to be as simple as possible, given the hardware on hand and the 
tmticipated task load. A retd-time executive (RTE) program, initiated by timed interrupts at various intervals, 
cidls appropriate task modules, luid repeals this process indefinitely. The use of interrupts enabled the 
processor to keep busy during slow (by processor standards) processes, such as generating servo command 
pulses. Under this conliguration. the chtdienge of programming the RTE was then reduced to a complex 
scheduling problem tunong a relatively smtdl number of processes which all have concise scope, known 
partuneters, and demonstrated chtuacteristics. The only immutable programming requirement was to arrange 
the process schedule of the RTE such thjit a Ciilled process can complete execution prior to the initiation of 
another process, tmd so that the resouices of interrupted processes are not needed by the interrupting process. 

This resetuch deuuls the inter-relations of the de.sign criteria used for this controller, to give the reader 
a better undersUmding of the ovendl system. From this understanding, present design decisions become 
appmeni, amt future development is facilitated. The future development described below is recommended to 
develop a more effective ;ind efficient controller design. 






B. RECOMMENDATIONS 


In the course of development, it became evident that several improvements would be necessary for the 
limd implementation of the system. Tliese included standardization of the command structure and 
improvements in data conversion :md triutsfer, in addition to some general system modifications. Also, other 
subsystems with which the conuoller must intentct, namely the aeronautical control module, were not 
completed as of this writing. These tueas iae recommended for future research and development and are 
briefly delineated below. 

1. Command and Control Structure 

The bttsic openition of the conuoller is to detennine the state of the aircraft, compare that state to 
a state commanded by the pilot, whether tluit pilot is a human or the conuoller executing a set of 
preprogrammed waypoints. Since the control module has not been completed, there is no standard command 
syntax in place. Neither is there ;i structure for communicating these commands to and firam the conuol 
module. For this research, a temponiry procedure ntuned flight_conuol() was written which simply generated 
vane comtnands in degrees. A future conuol module should have the capability to read the necessary flight 
data from the global registers, determine the commanded stale, and generate control vane angles compatible 
with the cmd_to_.servos() routine. It is this middle function that needs to be carefully defined. 

The control module is expected to output these commands for each of the standard three- 
dimensional conuol surfaces: itileron, eleviitor, tmd rudder. It is presently the responsibility of the 
cmd_to_scrvos() procedure to uanslate these commands into appropriate coordinated commands for the eight 
conuol vimes pliumed for insltdlation t)n the Archytas [Sto93]. This uanslation is cuiiently incomplete, 
especiidly considering that tlie tnuislation ptuameters must change as the aircraft Uansitions from vertical to 
horizonttil flight. This area requires tidditional study unless this Uanslation process is absorbed into a conuol 
module thiU incorporates both the llight_conUol() tuid cmd_to_servos() functions. 

2. Data Ceneration and Conversion 

Outside of the conuol :ilgorilhm. the conUoller’s main function is to gather and disseminate 
necessiiry data to appropriate functions. The taster this data ciin be generated, the better the conuoller can 
perfonn. Several ftictors tue impeding optimum perfonntuice, as described below. 

First, the direct memory ticcess (DMA) fonn of data uansfer should be used where possible. This 
would preclude the waste of processor resources to perform memory to memory copying of data. Several 
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accessory bixirds, specificidly the PCL-744 seritil card and the PCL-812 lab card advertise a DMA capability. 
This utility was attempted, but never successfully implemented during this research. 

Second, the serial ports ctui transfer dtiw more quickly. The serial card was set up at 9600 bps to 
match with other subsystems that h.id been designed to operate with a standard RS-232 serial port, which 
normitlly operate iU that speed. The ports of the PCL-744, however, can be configured as high as 38400 bps 
[PCL-744 Manuitl. p. 16]. Each port .should be optimized separately, since some of the connected 
subsystems, like the datalink, cim be configured to run at variable speeds, while other subsystems, like the 
GPS imd the IMU run only at 9600 bps. 

Third, the IMU is lixt slow. As explained in Chtipter ni, the fastest possible message fiequency 
would he 31.5 Hz. Empiric;)] data h:LS shown the actual message frequency to be closer to 20 Hz. To have 
new IMU dam for every control cycle requires slowing the cycle or increasing the output rate of the IMU. 
W;)tson Industries does offer vtu-ious options which can increase the speed of the IMU, and these options 
should be explored. 

Fourth, the speed of the daudink is too slow. As shown in Chapter HI, the dam transfer 
requirements for remote controlled operation from the ground is above the capacity of the datalink. This will 
become less of a factor as the UA V development progresses towards autonomous flight, but it will always be 
ex;icerb;ued by incretising the link tiverhetid as proptigation quality deteriorates. Field experimentation will 
show which dtita is more crucitJ to control ;ind which dam could be sent less frequently. Overall, for positive 
remote control, no more thtui 100 m.sec can elapse between pilot command input and the associated 
tnovemenl of the control surfaces |Kam93|. In the early smges of development, the datalink is the weakest 
:ind yet most impormnt link in the control process. 

3. General System Mndillcatinns 

Bec;iuse the d;it;Uink proved to he so unreliable, user menu selections were entered directly from 
the keybo:ud. When the key botad is removed to phice the controller in the aircraft, these menu programs must 
execute through the dattUink. Fortuimtely, bectiuse of the case smternents used to execute menu choices, the 
user interlace programs require only minor chtuiges to read user input from the dataUnk, rather than the 
console keyboard. 

Second, the GPS routines need to be fully implemented. The procedure read ensU was written in 
pUice of Twite’s procedure Sl;ive_gps0. which w;)s not fully completed. It is Twite’s program that decodes 
the data su-e:un from the GPS :ind phiccs the navigation in tt global structure, as discussed in Chapter IV. This 
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convenient iiecess to GPS data will not be available until Twite’s software is completely implemented. This 
includes the potentitU for accessing GPS datii other thtut the position change status message by uplinking 
commands to the GPS receiver through the PANDL gps->in [Twi94, p. 125], 

Third, the 25 pin serial connectors on the PCL-744 octopus cable are much too heavy and bulky 
for actual implementation. For the RS-232 connections, only eight wires have the potential of carrying 
signals tmd, because flow conu-ol is not used, only three wires are actually used. During actual 
implementation, it is recommended that customized cables be used. 

Last, a multi-tasking or multiple processor CPU board should be investigated. Even without the 
processing-intensive control algorithm, this controller is extremely constrained by real-time deadlines. The 
addition of other processing requirements could force the system to be run at an unacceptably slow interrupt 
intervid. Although upgrading to a faster CPU would ease the problem somewhat, a multi-tasking or 
segregated multiple processor environment should produce a better solution with higher flexibility and 
greater throughput. 

C. SUMMARY 

Through this resetuch. the goid of designing and building an UAV controller has been successfully 
completed. The resulting aggregation of hiudwtue and software represents a functional shell to which 
improvements can be made, and into which other subsystems, developed in the future, may be added. From 
the initial primary research question, down to the ftnal woiking implementation, this research quantifies the 
system mtuidates and documents the conceived solutions. This controller represents a proof-of-concept for 
unmanned control of air vehicles, and one thiit. with the addition of a suitable control module, is ready to fly. 
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APPENDIX A: REAL TIME EXECUTIVE SOURCE CODE 


^*****»*****»*»*************** DBFS H ********************************** 
PROGRAM INITIALIZATION 

**«**«********************»*******•****»***********«*********«************/ 
/*Note; MOXA-CL.obi and 812CL.lib must be linked into executable file */ 

# include <stdio.h> 

# include <stdlib.h> 

# include <conio.h> /* For clrscr and cprint */ 

# include <alloc.h> /* For coreleft and malloc */ 

# include <do8.h> /* For DOS and BIOS interrupts */ 

# include <setjinp.h> /* For ctrl-break handler */ 

#include “c:\pclB-802\Hb\c\head-c.h” /* For PCL-744 definitions */ 


VARIABLE DEFINITIONS 


l:iHl***********/ 


# define TRUE 1 

# define FALSE 0 


# define 

# define 

# define 

# define 

# define 

# define 

# define 

# define 

# define 

# define 

# define 

# define 


RTC_INT 0x70 
RTCJNDEX 0x70 
RTC_DATA 0x71 

REG_A - 

REG B 
REG_C 
REG_D 
INT_FLAG 
NMI_FLAG 0x80 
RATE_SET OxOB 
RATE 32 

PIC.STATUS OxAl 


OxOA 

OxOB 

OxOC 

OxOD 

0x40 


/* RTC fires interrupt 70h */ 
t* RTC Index Register I/O Address */ 
/♦ RTC Data Register I/O Address */ 


/* Periodic Interrupt Flag is bit 3 */ 
/* Non-masketble Interrupt Flag bit 4 */ 
/* Used to set control cycles per sec: */ 
/* 32768 «(RATE_SET - 1) *I 


/* Definitions for PCL-7 44 Serial I/O */ 
#define IMUPORT 3 

#define SGPS PORT 4 

#define DLPORT 5 

#define MGPS_PORT 10 
#define CR OxOD 

fdefine LF OxOA 

#defme lOMODE (BIT_8 I P.NONE I 
#define MODMODE 0x00 
#define HWMODE 0x00 


/* Port number from IMU */ 
I* Port number for Slave GPS Rcvr *! 
/* Port number to Data Link */ 
/* Port number for Master GPS Rcvr ♦/ 
/* Carriage Return is ASCII 13h */ 
/♦ Line Feed is ASCII lOh »/ 
STOP_l) I* 8-N-l (p. 12) */ 

/* DTR and RTS off (p.26) */ 
/* HW and SW flow Ctrl off (p.33) */ 


/* Definitions for GPS routines are in GPSDEFIN.H. Each GPS module 
contains its own prototypes, included in the file below: ♦/ 


#include “c:\borlandc\twitefin\gpsfun.h” 
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/* DEFS.h, Page 2 •/ 

SUBROUTINE PROTOTYPES FOR MAIN PROGRAM (Table of Contents) 


/* void niain(void); 
void menuCvoid); 
void initialize_hw(void); 
void check_hardware(void); 
void start_fmu(void); 
void quit_ftnu(void); 

unsigned char ReadRTC(unsigned char reg); 

void SetRTC(unsigned char reg, unsigned char value); 

/♦ void interrupt new_vector(void); 

void reset_int(void); 

void execute_cycle(void); 

int readJmuCPANDL *jbuffer); 

int read_gps(PANDL ♦buffer); 

void read_atod(void); 

void xmit_to_gnd(PANDL *buffer); 

int read_datalink(PANDL ‘buffer); 

void flight_control(int *thr, int ‘ail, int *elev, int *rud); 

void cmd_to_servos(int, int, int, int); 

void show_flight_data(void); 

void show_iniu(void); 

void show_gps_posit(void); 

void show_air_data(void); 

void show_servo_posit(void); 

void close_ports(void); 

void shut_down{void); 

void int_vector(void); 

void mem_dump(void); 

void show_regs(void); 

void bit_print(unsigned int v); 

void dos_cmd(void); 

int break_handler(void); 

void bootstrapCint input); 


struct T_GPS ‘gps; 

PANDL *imu_buf, *gps_buf, *gps_print, *dl_biif; 


/* Page 2 */ 
/♦ Page 3 ♦/ 
/* Page 5 ♦/ 
/♦ Page 8 ♦/ 
/* Page 10 */ 
/* Page 12 */ 
/♦ Page 13 */ 
/* Page 13 ♦/ 
/* Page 13 */ 
/• Page 13 */ 
/♦ Page 14 */ 
/* Page 15 */ 
/* Page 15 */ 
/• Page 16 •/ 
/♦ Page 16 ♦/ 
/♦ Page 16 ♦/ 
/* Page 17 */ 
/* Page 18 •/ 
/♦ Page 19 ♦/ 
/* Page 19 */ 
/* Page 20 */ 
/* Page 20 ♦/ 
/* Page 20 •/ 
/♦ Page 21 ♦/ 
/* Page 21 */ 
/* Page 22 */ 
/♦ Page 22 ♦/ 
/♦ Page 22 */ 
/♦Page 23*/ 
/* Page 23 */ 
/♦ Page 24 */ 
/♦ Page 25 ♦/ 


/♦ Variables for-AtaP */ 

extern pcl812(int, unsigned int ♦); 

unsigned int param[60]; /* PCL-812 parameter array ♦/ 

unsigned int data[20]; /♦ Conversion data buffer ♦/ 

unsigned int far *dat; 


/* Variables for Counter/Timer */ 
int datreg = 0x210; 
int conreg= 0x211; 


I* Ctr/timer board, base address */ 
/♦ Ctr/timer board, base addr+1 ♦/ 







Archytas Real-Time Executive Program (Page 1) 

Author: LT Peter M. Hoffman 

Written: 1 October 1993 

Revised: 1 June 1994 

Compiler: Borland C++ 2.0 

This RTE program provides the basis of the controller for the Archytas 
Unmanned Air Vehicle. Modifications to the flight_control() and 
cmd_to_servos() procedures could adapt this controller to any UAV 
using the same data path. 

This controller is the center of a multi-dimensional inter¬ 
disciplinary project collaborated by a number of students from 
various departments of the Naval Postgraduate School, Monterey, CA. 

Please see Thesis Document for complete details and explanation. 

# include “c:\control\defs.h” /* All definitions and prototypes */ 

int cyclecount = 0, vane_step = 0; 

int thr_cmd, ail_cmd, elev_cmd, rud_cmd; 

void interrupt new_vector(void); 

void interrupt (*old_vector)(); 

int ftnu_start_flag = FALSE; 

jmp_buf cbreak_rtn; 
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/* RTE, Page 2 */ 


void inain(void) 

The main program initializes the system, then calls menuO to 
interface with the user for further actions. 


/* Set UI) structures to hold data */ 

= mallocf sizeofl struct T_GPS)); 
imu_buf = mallocC sizeofl PANDL )); 
imu_huf->ptr = callocf 100, sizeoff char )); 
gps_buf = mallocC sizeofl PANDL )); 
gps_buf->ptr = callocf 500, sizeoft char )); 
dLbuf = mallocf sizeoR PANDL)); 
dl_buf->ptr = callocC 100, sizeoR char )); 


clrscrO; 


/* Set UP control-break resttme point */ 

iRsetjmp(cbreak_rtn) != 0) IclrscrO; printR“\nRestarting Program...”);) 


/* Begin user interface */ 
printR“\t\tArch^s Monitor Program”); 
printR“\n\nInitializing Hardware...”); 
initialize_hw(); 
menuO; 


} /* End Main */ 
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/♦ RTE, Page 3 »/ 


void menu(void) 

^/***************************<l^•***********^l*»****^,^Lt********************** 

This procedure interfaces with the user, querying for the desired 
response and invoking the appropriate routine. 

char ch; 


whiled) 1 

printft“\n\nCommand (T for help); “); 
scanf(“%s”, &ch); 
switch (ch) 1 
case ‘c’: 

check_hardware(): 
break; 
case ‘s’: 

start_finu(); 
break; 
case ‘q’: 

quit_fniu(); 
breEik; 
case ‘f: 

show_flight_data(); 
break; 
case ‘m’: 

nieni_dump(); 
break; 
case ‘r’: 

show_regs(); 
break; 
case ‘i’: 

int_vector(); 

break; 

dos_cmd(); 

break; 


/* Cheek Hardware */ 

/♦ Start FMU */ 
/* Quit FMU */ 
/* Flight Data */ 
/* Memory Dump */ 
/* Display Registers */ 
/* Interrupt Vector */ 
/* DOS command ♦/ 


• /* List Alternatives */ 

pnntf(“\n%s\n%s\n%s\n%s\n%s\n%s\n%s\n%s\n%s\n%s\n%s\n’’, 
“The following are valid commands;”, 


“(c)heck hardware”, 

“(sltart flight management unit”, 
“(q)uit flight management”, 
“(Dlight data menu”, 

“(m)emory contents display”, 
“(r)egister contents display", 
“(i)nterrupt vector display”, 
“(d)os command”, 

"(terminate program”); 
break; 






/*RTE,Page4*/ 
/* QUIT */ 


case‘t’: 

printft“\nTenninating Program...”); 
exit(O); 
default; 

puts(“\nNot a valid command. Type “ 
) /* End Switch */ 

) /* End While */ 

/* End Menu */ 


’ for help.”); 





I* RTE, Page 5 */ 


void initialize_hw( void) 

This procedure initializes the PCL-812, PCL-744 and PCL-830 
hardware boards for UAV controller operation. 

**************4:** ******»**4t)|c****«***4i*«*********»****** ****************/ 


int rtn_code, port, i; 

int gpstart[]= l‘@’,’@’,’B’,’a’,0x01,0x32,0x0D,0x0Al: 


I/O Port Address (SWl): 220h. 0 Wait States 
Trigger Mode (JPl): Internal 
IRQ Level (JP4): 5 
A/D Input Range (JP9): +/- 5V 
Parameter Array as follows: */ 


dat = data; 
param[0] = 0; 
paramil] = 0x220; 
param[4] = 5; 
param[5] = 50; 
param[6] = 100; 
param[7] = 0; 
paramis] = 0; 
paramtlO] = FP_OFF(dat); 
paramill] = FP_SEG(dat); 
param[12] = 0; 
param[13] = 0; 
param[14] = 5; 
paramLlS] = 0; 
paramEie] = 5; 
param[17] = 0; 


/* Board number */ 
/♦ Base I/O address */ 
/* IRQ level ; IRQ6 */ 
I* Pacer rate = 2M / (50 * 100) = 400 Hz */ 

/* Trigger mode: internal pacer trigger */ 
/* Non-cyclic mode */ 
/* Offset of A/D data buffer A ♦/ 
I* Segment of A/D data buffer A ♦/ 
/* Data buffer B offset: 0 if not used */ 
/* Data buffer B segment: 0 if not used */ 
/* A/D conversion number */ 
/* A/D conversion start channel */ 
/* A/D conversion stop channel */ 
/* Overall gain code, 0 : +/- 5V */ 


/* param[18] = FP_OFF(gain_array); FYI: Output Registers 
param[19] = FP_SEG(gain_array); 
param[45]: Error code 
param[46]: Return value 0 
param[471: Return value 1 */ 


pcl812(3, param); /* Func 3 : Hardware initialization */ 

if (param[45] != 0) I 

printff“\n PCL-812 Driver Initialization Failed!”); 
exitd); 


pcl812(4, param); /* Func 4 : A/D initialization */ 

if (param[45] 1= 0) i 

printff“\nA/D Initialization Failed!”); 
exitd); 

) 
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/* RTE, Page 6 */ 


/»*******♦****»»******** pcL-744 Initialization ************************/ 
for (port = 3; port <= 10; port++) ( /* Set up each port */ 

printfl"\nConfiguring port number %d (Cable #%d):”, port, port-2); 

/* Set I/O control narams */ 
rtn_code = sioJoctK port, B9600, lOMODE ); 
if (rtn_code != 0) 

printf(“\nI/0 control error on port %d.”, port); 


/* Set line control parameters */ 
rtn_code = sioJctrK port, MODMODE ); 
if (rtn_code != 0) 

printf(“\nLine control error on port %d”, port); 


/* Set flow ggntrfllparams*/ 
rtn_code = sio_flowctrl( port, HWMODE ); 
if (rtn_code != 0) 

printf(“\nFlow control error on port %d”, port); 


/* Last, open the port which enables it for I/O */ 

rtn_code = sio_open( port); 
if (rtn_code != 0) 

printf(“\nError opening port %d”, port); 


} /♦ End For port++ Loop */ 

/* Send ‘I’: tell IMU to begin sending */ 
rtn_code=sio_putch( IMUPORT, ‘I’); 
if ( rtn_code == 1) printf(“\n IMU initialized OK”); 
else printf(“\n IMU NOT initialized”); 


/* Initialize GPS to sen d position msg every sec */ 

rtn_code=sio_putb( SGPS_PORT, gpstart, 8); 

if ( rtn_code <= 0) printR“\n GPS NOT initialized”); 

if ( rtn_code == 8 ) printR“\n GPS initialized OK’); 


/* ggt T?i/Ry timeeutte l-sacaad */ 

rtn_code = sio_timeout( 18 ); 


/* Flush Rs and Is Bvifferg */ 
sio_flush( SGPS_PORT, 2); 
sio_flush( IMUPORT, 2); 
sio_flush( DLPORT, 2 ); 
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/* RTE, Page 7 */ 


/*** PCL.-830 Initialization (Am9513A chip) »*•*»***•»***♦**♦♦•**♦***•***/ 
f* This portion of initializeO written by Pat Moran. */ 

/* All values are decimal, but represent binary register settings. ♦/ 

/* See Am9513A Technical Manual for details */ 


outportb(conreg,255); 
outportb(conreg,23): 
outportbCdatreg, 176); 
outportb(datreg,65); 


/* Reset all board functions */ 
/* Select master mode register */ 
/* Low byte enables POUT, FI source */ 
/* Hi byte selects binary division */ 
/* Disable increment, 8 bit bus */ 
/* POUT on, divide by 1. */ 
/* RTE, Page 7 */ 


outportb(conreg,249): 
for (i=lp<=5;i++) 

{ 

outportb(conreg,i); 
outportbCdatreg,98); 
outportb(datreg,27); 

for (i=25;i<=29;i++) 

I 

outportb(conreg,i); 
outportb(datreg,0); 
outportb(datreg,31); 

) 

for (i=9p<=13;i++) 

1 

outportb(conreg,i); 
outportbCdatreg, 103); 
outportbCdatreg,5); 


I* Diable prefetch for write ops */ 


/* Select ctrs 1-6 */ 
/* Low byte: set modes of ctrs 1-5 in CMR */ 
/* High byte: no gating for ctrs 1-5 */ 


/* Load hold registers for refresh rate */ 
/* Load + Hold = Refresh Rate */ 
r* This combo gives 25 ms rate C40 Hz) */ 


/* Select load registers for pulse width */ 
/* Sets time for next pulse */ 


for Ci=233;i<=237;i-t+) outportbCconreg,i); 

outportbCconreg.i); /* Load & arm ctrs 1-5 */ 


outportCconreg, 127); 

printft“\nCompleted Initialization of Servos.”); 
1 /* End Initialize_HW ♦/ 
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/* RTE, Page 8 */ 


void check_hardware(void) 

)/♦♦♦♦♦♦♦♦♦»♦****»*»»»*»»♦**»»»»»»*»***»»***»♦»*»♦****♦*»»»*»****»**»♦*♦♦♦ 
This procedure checks that all the hardware is properly 
configured and operational. 


int i, card_type = 0x744, card_no = 1, rtn_code, port; 

char *buf = “Test String”; 

union REGS xreg, yreg; 

unsigned elist, drives=0, ports=0, printers=0; 

elist = biosequipO; /* Determine BIOS Equipment ♦/ 

if (elist & 0x0001) drives = ((elist & OxOOcO) » 6)+l; 
ports = (elist & OxOeOO) » 9; 
printers = (elist & OxcOOO) » 14; 

printf(“\nThis system has %d diskette drives, %d serial ports, %d printer ports 
drives, ports, printers); 

if ((ehst & 0x0()02)» 1) printf(“and a math co-processor.”); 

printf(“\nlt has %uK of RAM and %lu stack available.”, \ 
biosmemoiyO, coreleftO); 

rtn_code = sio_bank(card_type, card_no); /* Display address of PCL-744 card */ 
printf(“\nThe PCL-744 card is mapped to address %Fp”, rtn_code); 

rtn_code = sio_id( card_type, card_no); /* Display ID number of 744 card */ 
printf[“\nlt is card number %d”, rtn_code); 

for (port = 3; port <= 10; port++) ( /* Set up each port */ 

printf(“\n\nChecking port number %d (Cable #%d):”, port, port-2); 

/* Check I/O Control Params */ 
rtn_code = sio_getbaud( port); 

printf(“\nBaud rate of port %d set to %d”, port, rtn_code); 
rtn_code = sio_getmode( port); 

printfI“\nMode of port %d set to %d.”, port, rtn_code); 

/* Check Line Control Params */ 
rtn_code = sioJstatus( port); 
if (rtn_code < 0) 

printf(“\nError in status for port %d”, port); 

else 

printf(“\nModem line status of port %d is %d.”, port, rtn_code); 

/* Check Flow Control Params */ 
rtn_code = sio_getflow( port); 

printf(“\nHardware flow control of port %d set to %d.”, port, rtn_code); 
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/* RTE, Page 9 */ 


!* D.a.l.fl9Pbatk test */ 

if (sioJoopback( port, buf, 12 ) == 0) 

printR“\nPort %d loopback test OK.”, port); 

else 

printR“\nPort %d failed loopback test.” port); 

printfT“\n\nReview data for port above.\nPress any key to continue.”); 
getchO; /* Wait for key */ 

) /* End For port++ Loop */ 

printf[“\n\nParaineter Array for PCL-830 board set to:”); 
for (i = 0; i <= 17; i++) { 

if(i==10 I I i==ll)printft“\nparani[%3d] = %Fp” i, param[i]); 
else printR“\nparani[%3d] = %d”, i, paramlij); 

1 

) /♦ End Check_Hardware */ 
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/• RTE, Page 10 */ 


void start_fmu(void) 


This procedure sets up the real-time clock to provide periodic 
interrupts at 64 Hz which will trigger the flight management unit. 

unsigned char value, bit_set, new_value; 

if (fmu_start_flag == TRUE) ( /* Check if already started */ 

printfl“\nThe FMU has already been started.’’); 
return; 


printf['‘\n\n Starting the Flight Management Unit.”); 

/* Get old vector number for posterity */ 
old_vector = getvectCRTCJNT); 

printfl“\nThe address of the old vector is: %Fp\n”, old_vector); 

/* Now set RTC to generate interrr upt at rate set in DEFS.h */ 

/* Alter interrupt rate to new rate (32768 » RATE_SET - 1) *! 
value = ReadR'rC(REG_A); /* Read register A *! 

bit_set = value & OxFO I RATE_SET; /* Lowest 4 bits sets rate of int *! 
SetRTC(REG_A, bit_set); /* Set to new rate of periodic int *! 

new_value = ReadRTC(REG_A); 

printf(“\nReg A was %x, now %x with new rate set.”,value, new_value); 

/* Enable periodic interrupts with the RTC *! 

disabled; 

value = ReadRTC(REG_B); I* Read register B */ 

bit_set = value I INT_FLAG; I* Enable periodic interrupts */ 

SetRTC(REG_B, bit.set); /* on IRQ 8 (Int 70). */ 

new_value = ReadRTC(REG_B); 

printf(“\nReg B was %x, now %x with int flag set.”,value, new_value); 

/* Chane? intemipt vertgr rwi piy program *■! 

disabled; I* Disable interrupts when changing */ 

setvect(RTC_INT, new_vector); 

enabled; 

printf(“\nlnstalled new vector: %p\n”, new_vector); 


value = ReadRTC(REG_C); 


/* Clear pending int by reading reg ♦/ 










/♦ RTE, Page 11 ♦/ 


/* Initialize PIC to enable intemints */ 

value = inportb(PIC_STATUS); /* Read PIC Status Register */ 

bit_set = value & Oxfe; 

outportb(PIC_STAnjS, bit_set); /* Clear bit 0 to enable ints */ 

new_value = inportb(PIC_STATUS); 

printfl[“\nPIC mask was %x, now %x with bit 0 cleared.”,value, new_value); 
enabled; 

fmu_start_f]ag = TRUE; 

1 /* End Start_FMU */ 
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/* RTE, Page 12 */ 


void quit_fmu(void) 

j/************************* ************************************************ 

This procedure stops the periodic interrupt, effectively halting the 
flight management unit, and resets the real-time clock chip back to 
its original configuration. 


unsigned char value, bit_set, new_value: 

if (fmu_start_flag == FALSE) { /* Make sure it has been started */ 

printfl“\nThe fmu has not yet been started.”); 


else ( 

printPt“\n\n Stopping the Flight Management Unit.”); 


/* Put system back to normal */ 
/* First clean up RTC */ 
disableO; 


/* Clear periodic interrupt bit */ 
value = ReadRTC(REG_B); 
bit_set = value & OxBF; 
SetRTC(REG_B, bit_set); 


/* Disable interrupts while changing */ 


new_value = ReadRTC(REG_B); 

printfl[“\nReg B was %x, now %x with int flag clrd.”,value, new_value); 


/* Reset rate to 1024 Hz */ 
value = ReadRTC(REG_A); 
bit_set = value & OxFO I 0x06; 
SetRTC(REG_A, bit_set); 


new_value = ReadRTC(REG_A); 

printfT“\nReg A was %x, now %x with new rate set.”,value, new_value); 

/* Reset interrupt vector to original value */ 

setvectCRTCJNT, old_vector); 

enabled; 

printff'NnThe cyclecount is: %d\n”, cyclecount); 

fmu_start_flag = FALSE; 

) /* End Else */ 

} /» End Quit_FMU */ 
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/* RTE, Page 13 */ 


unsigned char ReadRTC( unsigned char reg) 


This function returns the value of the specified register on the 
real-time clock chip. 


unsigned char reg_nmi, value; 


reg_nmi = reg 1 NMI_FLAG; 
outportb (RTC_INDEX, reg_nmi); 
value = inportb (RTC_DATA); 
return value; 

1 /* End Read_RTC */ 

!* Disable Non-Maskable Int */ 
/* Tell CMOS which reg to read ♦/ 
!* Read value of register */ 

void SetRTCf unsigned char reg, unsigned char value ) 

This procedure sets a new value into the specified register 
of the real-time clock chip. 

unsigned char reg_nmi; 


reg_nmi = reg 1 NMI_FLAG; 
outportb (RTCJNDEX, reg_nmi); 
outportb (RTC DATA, value); 

) /* End Set RTC */ 

/* Disable Non-maskable Int */ 
/* Tell CMOS which reg to set */ 
/♦ Write value to register ♦/ 

void interrupt new_vectord 


This is the flight management unit procedure that is run on each 
occurrence of the periodic interrupt. 

********************************** i»*******»***************»»*************/ 

cyclecount-n-; 
cyclecount %= RATE*10; 
resetJntO; 
execute_cycled; 

1 /* End New_Vector */ 

/* Count number of cycles */ 
/* Normalize count every 10 seconds */ 
/* Reset Interrupt to enable next one */ 
!* Do something constructive */ 

void reset_int(void) 



This procedure resets the real-time clock chip and the PIC chips 
in order to facilitate another periodic interrupt. 

unsigned char value; 

value = ReadRTC(REG_C); /* Must read reg C to get another int ♦/ 

disabled; 

outportbfOxOaO, 0x20); /* Send non-specific EOI to slave PIC ♦/ 

outportb(0x20, 0x20); /* and master PIC */ 

enabled; 

I /♦ End Resetjnt */ 
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t* RTE, Page 14 ♦/ 


void execute_<^ycle(void) 

This procedure is the heart of the controller. It is the routine 
that is invoked during every occurrence of the real-time clock 
interrupt, coordinating the execution of other modules which 
comprise the control and communication processes of the UAV. 

unsigned char value, bit_set; 
int imu_ok, gps_ok, dl_ok; 

value = inportb (0x61); 

bit_set = value '' 0x02; /* Toggle speaker enable bit */ 

outportb(0x61, bit_set); /* (Sounds like the motor is running) */ 


/* sio_putb( DLPORT, “GPS: 5); 
Slave_gps( gps); 
xmit_to_gnd( &gps->out); 
free( gps->out.ptr); 


Calls to Eric Twite’s Stuff 
(Not yet operational) 


dl_ok = read_datalink( dl_buf); /* Read uplink every cycle ♦/ 

/* Put code to deal with info from datalink uplink here ♦/ 


if (cyclecount % 4 == 0) { /* Read IMU every 4th cycle */ 

imu_ok = read_imu( imu_buf); /* Send every 0.5 sec */ 

if ( cyclecount % (RATE/2) == 0 && imu_ok ) ( 

sio_putb( DLPORT, “IMU: “, 5); /* IMU label in data stream *! 

xmit_to_gnd( imu_buf); 


ificyclecount % (42) == 0) 1 

gps_ok = read_gps( gps_buf); 
if(gps_ok) I 

sio_putb( DLPORT, “GPS: “, 6); 
xmit_to_gnd( gps_buf); 


I* Read GPS every 1.3 sec *! 

/* If full msg rcvd, */ 

/* also send to ground */ 
/* with data stream label */ 


read_atod(); 


/* Read AtoD every cycle */ 


/* Last, with all flight data in hand, control aircraft */ 
flight_control( &thr_cmd, &ail_cmd, &elev_cmd, &rud_cmd); 
cmd_to_servos( thr_cmd, ail_cmd, elev_cmd, rud_cmd); 


I /* End Execute_Cycle *1 


79 






/* RTE, Page 15 */ 


int read_imu( PANDL ‘buffer) 

This procedure reads into a pre-estsiblished buffer the data 
from the onboard Inertial Measurement Unit. 

int eol = CR; 
int queue; 

queue = sio_iqueue( IMUPORT); 

if (queue > 100) queue = 100; /♦ Truncate to size allocated in main */ 

if (queue > 38) 1 /* Buffer has at least 1 full + partial msg */ 

buffer->len = sio_linput( IMUPORT, buffer->ptr, queue, eol); 
buffer->len = sio_read( IMUPORT, buffer->ptr, 38); 

I 

else if (queue >0) /* or has at most 1 full msg (usual condition) */ 

buffer->len = sioJinpuW IMUPORT, buffer->ptr, queue, eol); 

else 

buffer->len = 0; /* or has nothing in the buffer */ 

if (buffer->len == 38) return TRUE; /* Test if message is complete*/ 

else return FALSE; 

1 /* End ReadJMU */ 


int read gps( PANDL ‘buffer) 


This procedure reads into a pre-established buffer the data 
from the onboard Global Positioning System. 

t*************4t*t*»4i4,n,t**t.tt**********»********************************/ 

int eol = LF, queue; 


queue = sio_iqueue( SGPS_PORT ); /* How long is rev queue? */ 

while (queue > 135) 1 /‘ Pare down to last 2*68-1 chars */ 

queue -= 135; /* (At most 1 full message) */ 

if (queue < 68) queue += 68; /* (But at least 1 full message) */ 

if (queue > 500) /* Max buffer space 500 bytes */ 

buffer->len = sio_read( SGPS_PORT, buffer->ptr, 500); 

else 


it 1 fulLmsg exists in the gueue t tnaybe.a partial msg */ 

/* If partial msg exists, read it away */ 
1 = sio_linput( SGPS_PORT, buffer->ptr, queue, eol); 


/* Now, only 1 full msg should exist in the oueue. so read it */ 
buffer->len = sio_linput( SGPS_PORT, bulfer->ptr, queue, eol); 


if (buffer->len == 68) return TRUE; /♦ Test to make sure full msg */ 

else return FALSE; 

) /* End Read_GPS */ 
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/* RTE, Page 16 */ 


void read_atod(void) 

This procedure calls PCL-812 intrinsic function 5, which triggers an 
A/D conversion on analog data inputs as set in the param array. 

/* Record AT? Conversions */ 

pcl812(5, param); /* Func 5 : Pacer trigger A/D conversion */ 

if (param[45] != 0) /* with software data transfer *! 

printft“\nA/D Conversion Failed!”); 

} /* End Read_AtoD */ 


void xmit to gnd{ PANDL *bufFer) 

This procedure transmits the contents of the buffer to the ground 
through the datalink. 


int strglen, txbuff; 
if (buffer->len > 0) ( 

txbuff = sio_offee( DLPORT); /* Get free space in xmit buffer */ 

if (buffer->len < txbuff) { /* If enough buffer space, send */ 

strglen = sio_putb(DLPORT, buffer->ptr, buffer->len); 
if(strglen==0)l /* Else */ 

sio_flush{DLPORT, 1); /* Get rid of the old data */ 

strglen = sio_write(DLPORT, “WARNING: Buffer cleared! 25); 
stiglen = sio_write(DLPORT, buffer->ptr, buffer->len); 


) /* End Xmit_to_Gnd "'/ 


int read_datalink( PANDL ‘buffer) 

This procedure reads the contents of the datalink’s receive buffer 
contmmng information sent from the ground through the datalink. 

int queue, eol = 


queue = sio_linput(DLPORT, buffer->ptr, 100, eol); /* Get queue length */ 
if (queue >0)1 /* If something is in queue, read it */ 

queue = sio_read(DLPORT, buffer->ptr, 2); /* Read length of msg */ 

buffer->len = atoi(buffer->ptr); /* Convert length to an integer */ 


/* Read in buffer of snecified lenrlh */ 

queue = sio_read(DLPORT, buffer->ptr, buffer->len); 

return TRUE; 


else return FALSE; 

) I* End Read_Datalink */ 


/* If nothing waiting in buffer, continue */ 












/* RTE, Page 17 ♦/ 


void flight_control(int *thr, int *ail, int ♦elev, int *rud) 

jy************************************************************************ 

This procedure is a place holder for the actual control algorithm 
being designed by the Aeronautical Engineering Department. 

The procedure envisioned here will perform appropriate data filtering 
and will use the filtered data to calculate the necessary control 
surface positions. The output of this procedure is the angle of each 
of the standard control surfaces. The cmd_to_servos procedure will 
convert these standard control surfaces into individual control vane 
angles. This conversion will differ depending on the mode of flight, 
whether vertical or horizontal. 

***»**•*************•****************************************************/ 
/* Get or calculate pilot commands */ 

/* Calculate control surface inputs */ 

/* The steps below are just a demo to exercise the servos to their 
lull extension in increments of 2 degrees until replaced by the 
actual control algorithm */ 

*thr = 100; /* Throttle stays constant */ 

vane_step += 2; /* Increase vtines 2 deg each cycle */ 

vane_step %= 200; /* All vanes go -30 to +30 deg */ 

*ail = vane_step; 

*elev = vane_step; 

*rud = vane_step; 

/* Delete global variable step vane when this test routine deleted */ 

1 /* End Flight_Control */ 






/* RTE, Page 18 */ 


void cmd_to_servo8(thr, ail, elev, rad) 

/* Written by LCDR Pat Moran 5/14/93 */ 

/♦ Originally called chgangleO - see thesis description */ 

/* Basic PWM routine by LT Paul Merz [Mer92] */ 

/* Demo to move aileron, rudder, elevator, & throttle from 2 joysticks. ♦/ 

/* Blends 3 degrees-of-freedom into 4 independent vane commands. */ 


int i,hibyte,lobyte,angle,vane[5]; 

vane[0] = ail/4 + rud/2; 
vaneil] = ail/4 + elev/2; 
vane[2] = ail/4 - rad/2; 
vane[3] = ail/4 - elev/2; 
vane[4] = thr; 
outportb(conreg,223); 

for (i=0;i<=4;i++) 1 

angle=(( 1900/206)*(vane[i])+600); 

hibyte=(angle/256); 

lobyte=(angle-hibyte*256); 

outportb(conreg,(i+9)); 

outportWdatregjlobyte); 

outportb(datreg,hibyte); 

1 

for (i=233;i<=237;i++) 
outportWconreg,!); 

outportb(conreg, 127); 

) /* End Cmd_to_Servos */ 


/* VI; Translation algorithm fin 3 */ 
/* V2; control surfaces to 4 vanes */ 
/* V3; */ 

!* V4; ♦/ 

/* Throttle needs no conversion */ 
/* Disarm counters 1-5 */ 


/* Convert fin deg to dig # ♦/ 
/* Calc high byte, residue left */ 
/* Calc low b)fte fin residue */ 
/* Load counters 1-5 */ 
/* Load low byte */ 
/♦ Load high byte */ 


/♦ Set toggle high for counters 1-5 */ 
/* Load & arm counters 1-5 */ 
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void show_flight_data(void) 


/* RTE, Page 19 *! 


This procedure queries the user to determine which flight data to 
display and calls the appropriate routine. 

char ch; 


printfl“\n%sSn%s\n%s\n%s\n%s\n%s\n\n%s”, 

“Display which data?”, 

“{g)ps position”, /* Can list other gps data here too */ 

“(i)mu data”, 

“(a)ir data”, 

“(s)ervo positions”, 

“Choice: “); 
scanfi:“%s”, &ch); 
switch (ch) 1 

case ‘g”: /* GPS Position */ 

show_gps_posit(); 
break; 

case ‘i’: /* IMU Data */ 

show_imu(); 

case ‘a’: /* Analog Air Data ♦/ 

show_air_data(); 
break; 

case ‘s’: /* Servo Position */ 

show_servo_posit(): 
break; 

default: 

printf(“\nData choice not recognized!”); 
return; 

} /* End Switch ♦/ 

} /* End Show_Flight_Data */ 


void show_imu(void) 

This procedure prints the most recently acquired IMU data. 


printft“\nLatest IMU data; %d charactersAn”, imu_buf->len); 
for (i = 0; i < imu_buf->len; i++) ( 
putchar(imu_buf->ptr[i]): 
if (i % 4 == 0) putcharC'); 

I 

I /* End ShowJMU */ 
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/* RTE, Page 20 */ 


void show_gps_posit(void) 

This procedure prints the most recently acquired GPS data. 


**«/ 


/* To Print from Twite’s GPS stru cture, when complete */ 
printf(‘‘\nLatest GPS position;\nLat: %d.%d N, Long: %d.%d W”,\ 
gps->pcs.Iatitude.degrees, gps->pcs.latitude.minutes, \ 
gps->pcs.longitude.degrees, gps->pcs.longitude.minutes); 


/* To print from gps buf raw data buffer */ 

gps_print = Bin_to_ascii( gps_buf, 4); /* Convert to ASCII chars ♦/ 

printf(“\nLatest GPS data: %d / %d characters.\n”, \ 
gps_buf->len. gps_print->len); 

for (i = 0; i < gps_print->len; i++) putchar(gps_print->ptr[i]); 

free(gps_print->ptr); 

free(gps_print): 

) /* End Show_GPS_Posit */ 


void show_air_data(void) 

This procedure prints the most recently acquired A/D data. 

unsigned int i; 
float DataBuf; 

/* Calculate analog values from raw data in data array */ 

for (i = 0; i < param[16]; i++) ( 

DataBuf = datali] & OxFFF; 

DataBuf = (10 ♦ DataBuf / 4096) + (-5); 

/* Calculations: 

10 : A/D input range (-5V to 5V) 

4096 : Full scale 12 bit A/D data 

DataBuf : A/D input data masked to 12 bits 
(-5) : A/D input base “-5” V 

*/ 

printf(“\ndata[%3d] = % 1.2f V returned as %x”, i, DataBuf, data[i]); 
) /* End For all data entries */ 

I /* End Show_Air_Data */ 


void show_servo_posit(void) 

ly*************************************************** 

This procedure prints the present position of all serv 

printf(“\nThr: %d, Ail: %d, Elev: %d, Rud: %d”, \ 
thr_cmd, ail_cmd, elev_cmd, rud_cmd); 

1 /* End Show_Servo_Posit */ 
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/* RTE, Page 21 */ 


void close_ports (void) 

y***********************i.^i***ttt*t*m»****»***t*tL*m*tti^**»m*»*»********* 

This procedure closes all serial ports on the PCL-744 card and 
flushes transmit and receive buffers for each port. 

*****************************tt,*^t:^tt**************t**********************/ 

int port, rtn_code; 

for (port = 3; port <= 10; port++) I 
rtn_code = sio_close( port); 
if (rtn_code != 0) 

printf(“\nError closing port %d”, port); 

else 

printfi:“\nClosed port %d”, port); 
sio_flush( port, 2); 

I /* End For all ports */ 

) /* End Close_Ports */ 


void shut_down(void) 

This procedure is invoked at program exit to ensure that the system, 
including communication ports, ISR vectors, and allocated memory, is 
properly terminated and returned to its normal operating configuration. 


quit_fmu(); /♦ Stop the flight management unit */ 

close_ports(); /* Close and flush all ports */ 

free(gps); /* Free all globally allocated memory */ 

fTee(imu_buf->ptr); 

free(imu_buf); 

free(gps_buf->ptr); 

free(gps_buf); 

free(dl_buf->ptr); 

free(dl_buf); 

1 /* End Shut_Down */ 
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/* RTE, Page 22 ♦/ 


void int vector(void) 

This procedure prints the address registered for the ISR of the 
interrupt number given by the user. 


void interrupt (*int_handler)(); 
int intno; 

printR“\nEnter interrupt number in hex: “); 
scanfi“%x”, &intno); 
int_handler = getvect(intno); 

printR“\nThe address of the handler is: %Fp\n”, int_handler); 
I /* End Int_Vector */ 


void mem_dump(void) 


This procedure prints the values of a given portion of memory. 

******t:*******************************************************t**********/ 

char far *far_ptr; 

printfl;“\n\nEnter begin memory address to dump (eg. POOO.EOOO):"); 

scanf(“ %p”, &far_ptr); 

printf(“\nHow many bytes to display? “); 

scanR“%d”, &n); 

printfl“\nDump of %d bytes at %Fp\r\n”, n, far_ptr); 
for(i=0; i<n; i++) ( 

printR“\n%Fp %Fx”, (far_ptr+i), *(far_ptr+i)); 

I 

1 /* End Mem_Dump */ 


void show_regs(void) 

|^********************************»**»******»»****«»*******4t»:tr4L******t*t« 

This procedure prints the current values of all CPU and segment 
registers. 

union REGS xr, yr; 
struct SREGS sr; 

segread(&sr); 

printf(“\nax = %x, bx = %x, cx = %x, dx = %x”, \ 
xr.x.ax, xr.x.bx, xr.x.cx, xr.x.dx); 
printR“\nsi = %x, di = %x, cflag = %x, flags = \ 

xr.x.si, xr.x.di, xr.x.cflag); 
bit_print(xr.x. flags); 

printff“\ncs = %x, ds = %x, es = %x, ss = %x”, \ 
sr.cs, sr.ds, sr.es, sr.ss); 

I /* End Show_Regs */ 
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!* RTE, Page 23 */ 


void bit_print(unsigned int v) 

This procedure prints the binary representation of the given 
hexidecimal number. 


int i, mask = 1 « 15; 


printf(“%x = v); 

for (i = 1; i <= 16; i++) { 

putchar(((v & mask) == 0) ? ‘0’: ‘1’); 
V «= 1; 

if (i % 4 == 0) putcharC ‘); 

} /* End Bit_Print */ 


void dos_cmd(void) 

This procedure invokes a DOS diell. 


char cmd[40]; 


printf(“\nDOS COMMAND:> “); 

gets(cmd); 

system(cmd); 

1 /* End DOS.Cmd */ 











/♦ RTE, Page 24 */ 


int break_handler(void) 

This procedure is invoked upon a control-break or control-c sequence 

from the keyboard. It gives the user more flexibility in determining 

how extensively he desires to reset the system. 

************************** *»»******* 4 >***************************»*** 4 <****^ 

char ch; 

union REGS xreg, yreg; 

printR“\n%s\n%s\n%s\n%s\n%s\n%s\n%s\n%s”, 

“Why did you break?”, 

“(c)old reboot machine”, 

“{w)arm reboot machine”, 

“(r)estart program (reinitialize hardware)”, 

“(g)o back to main menu”, 

“(Germinate program", 

“Choice: “); 
scanf(“%s”, &ch); 
switch (ch) { 

case ‘c’: /* Cold Reboot ♦/ 

bootstrap(O); 
break; 

caseV: /* Warm Reboot */ 

bootstrap(l); 
break; 

case V: /* Restart Program */ 

shut_down(); 
longjmp(cbre£ik_rtn, 1); 
break; 

case ‘gf: /* Main Menu *! 

menuO; 

case't’: ’ /*QUIT*/ 

printf(“\nTerrainating Program...”); 
exit(O); 

default; 

menuO; 

I /* End Switch */ 

I /* End Break_Handler *! 








/• RTE, Page 25 */ 


void bootstrapCint input) 

union REGS reg; 
void (far *reboot)(void); 
int far *boottype; 


/* Set Far Pointers to the Boot Sector */, 
FP_SEG{reboot) = Oriffif; 
FP_OFF(reboot) = 0; 

FP_SEG{boottype) = 0x40; 
FP_OPF(boottype) = 0x72; 


/* Issue a DOS disk reset request to flush caches*/ 

reg.h.ah = OxOd; 

int86(0x21, &reg, &reg); 


/* Set boot type and execute reboot V 

♦boottype = (input ? 0x1234 ; 0); /* 0 = Cold, 1 = Warm ♦/ 

(*reboot)(); 

1 /* End Bootstrap */ 


/* End of Real-Time Executive Program */ 
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APPENDIX B: LIST OF VARIABLES 


The following is a reference listing of the definitions of all variables used in the Real-Time Executive source 
code shown in Appendix A. (G) indicates a globally maintained variable. 


angle 

bit_set 

*boottype 

buffer->len 

bufrer->ptr 

ch 

cyclecount 

*dat 

data[20I 

DataBuf 

dl_buf 

dl_ok 

eoT 

fmu_start_flag 

gps_buf 

gps_start 

gp$_ok 

Mbyte 

imu_buf 

imu_ok 

intno 

lobyte 

•old_vector 

parani[60| 

port 

queue 

♦reboot 

rtn_code 

sr, XT, yr 

strglen 

txbuff 

value 

vane 

vane_step 


Value of digital representation of servo command angle 

Bit value to be written to register from the Real-Time Clock (RTC) chip 

Pointer to memory location specifying hard or cold boot 

Lenght field of PANDL structure. Represents the length of the buffer. 

Pointer field of PANDL structure. Points to the actual data buffer. 

Pointer to position in program to return to after control-break (G) 

Variable to hold user response to menu selection 
A counter incremented on every cycle of a control loop (G) 

The pointer to the data array (G) 

An array in which the PCL-812 stores the results of its A/D conversions (G) 
Value of actual voltage calculated from A/D conversion data 
PANDL to store raw data received through the dataUnk (G) 

Boolean set true if message received on dataUnk 
Character which ends complete message from IMU or GPS 
Pointer to memory location to begin inspection 
Boolean variable toggled on when FMU is started (G) 

PANDL to receive raw data retrieved from GPS receiver (G) 

Array to hold start sequence to be sent to GPS receiver 
Boolean set ffue if GPS message received is complete 
Value of high byte given to PCL-830 for the PWM signal 
Loop increment used in various places 
PANDL to receive raw data retrieved from IMU (G) 

Boolean set true if IMU message received is complete 
Number of interrupt for which requesting ISR vector address 
Value of low byte given to PCL-830 for the PWM signal 
Pointer to hold value of old interrupt ISR vector (G) 

Value of register read from RTC after a modification 

An array of parameters used to configure the PCL-812 board (G) 

For loop increment to configure all ports 

Length of receive queue buffer from IMU or GPS 

Pointer to memory location to jump to causing reboot 

Value of register read from the RTC with Non-Maskable Interrupt (NMI) bit set 

Code returned from execution of PCL-744 I/O program 

Values read from computer internal registers 

Number of characters transmitted to datalink buffer 

Length of free space available in datalink transmit buffer 

Value of register read from the RTC 

/krray holding vane servo commands for each of the servos 

Temporary variable holding command for control vane position (G) 
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All-in-One 486 CPU Card 
140 with Cache 



Introduttion 

We designed the PCA-6146 for users 
who require high speed system 
performance in their industriai PC 
applications. The card is available in five 
80486 CPU versions: 80486SX-25. 
80486SX-33, 80486DX-33, 80486DX2- 
50 or 80486DX2-66. The card's all-in- 
one design includes memory caching, 
disk drive controllers, a watchdog timer 
and serial/parallel ports. We give every 
card a 24-hour dynamic burn-in test to 
ensure component reliability in harsh 
environments at temperatures up to 
140«F (60”C). 

With the PCA-6146 plugged into your 
passive backplane, your industrial PC 
becomes a true 32-bit 80486 
compatible computer system. 

The card’s highly compact size, 
numerous features and unmatched cost/ 
performance ratio make it ideal for 
high-end industrial applications where 
high CPU speed, minimum space and 
short MTTR are crucial. 


Each PCA-6146 ships with either an 
80486DX-33 MHz, 80486DX2-50 MHz 
or an 80486DX2-66 MHz CPU. These 
state-of-the-art CPUs feature an on-chip 
math coprocessor and an 8 KB cache 
memory for floating point calculations 
and fast memory access. 256 KB of 
2nd-level cache memory allows the card 
to run at Landmark speeds in excess of 
150 MHz. 

Other standard features include two 
RS-232 serial ports, one parallel/printer 
port, an IDE hard disk drive interface, a 
floppy disk controller, a watchdog 
timer, piggyback module connectors 
and an on-board keyboard connector. 
You can configure system memory to 
anywhere from 1 MB to 16 MB using 
256 KB, 1 MB or 4 MB SIMM DRAM in 
the PCA-6146’s four memory sockets. 


features 

• Completely 80486 PC/AT compatible 

• 32 to 140”F (0 to 60”C) operating 
temperature 

• Watchdog timer 

• Optional Flash/RAM/ROM Disk 
Piggyback Module (PCD-8931) and/or 
Flat-panel/CRT VGA Piggyback 
Module (PCA-6443) install on the 
piggyback connector 

• 80486 processor and AMI BIOS 

• ETEQ’s Cougar chipset 

• 256 KB 2nd-level cache memory 

• Up to 16 MB of on-board DRAM 

• Built-in IDE (AT bus) hard disk drive 
interface 

• Built-in floppy disk drive controller 

• Two serial RS-232 ports 

• One parallel/printer port 

• On-board keyboard connector 

• Lithium battery back-up for real-time 
clock/calendar 
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PCA-6147 


Spetifitafions 

• CPU: 80486SX/DX/DX2-25/33/40/50/66 MHz 

• Cache memory size: 8 KB on-chip and 256 KB 2nd level 

• Bus Interface: ISA (PC/AT) bus 

• Data bus: 32 bit 

• Processing ability: 32 bit 

• Coprocessor: Socket for Weitek 4167 

• RAM memory: 1 MB to 64 MB, uses four banks of SIMM 
sockets composed of eight 30 pin sockets and two 72-pin 
sockets {72-pin sockets accept 1, 2,4, 8 and 16 MB 
SIMMs) 

• Shadow RAM memory: Supports system and video BIOS of 
up to 256 KB in 32 KB blocks 

• IDE hard disk drive interface: Supports up to two IDE (AT 
bus) hard disk drives. BIOS enabled/disabled 

■ Floppy disk drive Interface: Supports up to two floppy disk 
drives, 5.25- (360 KB and 1.2 MB) and/or 3.5- (720 KB and 
1.44 MB). BIOS enabled/disabled 

• Bi-directional parallel port: Configurable to LPT1, LPT2, 
LPT3 or disabled. Standard DB-25 female connector 
provided 

« Serial ports: Two RS-232 serial ports can be Individually 
set to COM1, COM2 or disabled. Each can be accessed 
through a DB-9 male connector 

• Real time clock/calendar: Dallas DS-1287 with lithium 
battery back-up for 10 years of data retention 

• Watchdog timer: Jumper configurable to, always disabled 
or software enabled/disabled. The timer interval is 1.6 sec. 
Your program uses I/O ports hex 043 and 443 to control the 
watchdog timer and generate a system reset or IRQ15 

• Piggyback connector: 16-bit bus connecter (64 * 36 pins) 
for expansion modules 

• DMA channels: 7 

• Interrupt levels: 15 

• Keyboard connector: A 6-pin mini DIN keyboard connector 
is located on the mounting bracket for easy access. An 
external keyboard adapter is included. An on-board 
keyboard pin header connector is also available 

• Bus speed: 8 MHz 

• System performance (w/804860X-50 MHz CPU): 200 MHz. 
Landmark speed VI.14; 167 MHz, Landmark speed V2.0 

• Max. power requirements: +5 V @ 2.5 A 

• Power supply voltage: 

+5 V (4.75 V to 5.25 V), +12 V, -12 V 

• Operating temperature: 32 to 140°F (0 to 60°C) 

• Board size: 13.r(L)x4.8'(W)(334mmx122mm) 

• Board weight: 1.2 lbs (0.5 Kg) 


Ordering Information 

□ PCA-6147-33/Bare: All-in-one 80486 CPU Card without 
CPU. Includes 256 KB cache memory, users manual, IDE 
hard disk cable, floppy drive cable and parallel port adapter 

□ PCA-6147SX-25/0K: Same as above but with 25 MHz 
80486SX CPU installed 

a PCA-6147SX-33/0K: Same as above but with 33 MHz 
80486SX CPU installed 

□ PCA-6147DX-33/0K: Same as above but with 33 MHz 
80486DX CPU installed 

a PCA-6147DX-50/0K: Same as above but with 50 MHz 
80486DXCPU installed 

a PCA-6147DX2-50/QK; Same as above but with 50 MHz 
80486DX2CPU installed 

□ PCA-6147DX2-66/DK; Same as above but with 66 MHz 
80486DX2 CPU installed 


On-board POST diagnostk lEDs 
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Spe€ifitations 

• CPU: 80486SX/DX/DX2-25/33/50/66 MHz 

• Cache memory size: 256 KB 

• Bus interlace: ISA (PC/AT) bus 

• Datd bus: 32 bit 

• Processing ability: 32 bit 

• Chipset: ETEQ’s Cougar chipset 

• RAM memory: 1 MB, 4 MB and 16 MB. Uses 256Kx9 
(SIMM-256-8), 1Mx9 (SIMM-1000-8) or4Mx9 (SIMM- 
4000-8) SIMMs with access time of 80 ns or less 

• CPU Comparison: 



• Shadow RAM memory: Supports up to 256 KB of memory 
in 16 KB blocks for system and video BIOS 

• Hard disk drive interface: Supports up to two IDE (AT-Bus) 
hard disk drives. Jumper enabled/disabled 

• Floppy disk drive interface: Supports up to two floppy disk 
drives: 5Vt (360 KB and 1.2 MB) and/or ZW (720 KB and 

1.44 MB). Jumper enabled/disabled 

• Parallel/printer port: 

Configurable to LPT1, LPT2, LPT3 or disabled. A standard 
female DB-25 connector is provided 

• Serial ports: Two RS-232 serial ports Individually 
configurable to COM1, COM2 or disabled. Each port Is 
accessed through Its own male DB-9 connector 

• Real time ciock/calendar: 

Real time clock/calendar with lithium battery back-up 
(3.6 V @ 850 mAH). External battery connector provided 

• Watchdog timer: Jumper configurable to always ON, always 
OFF, or programmable ON/OFF, The time-out interval is 
jumper selectable to 1.5,15 or 150 seconds 

• Piggyback connector 64-pin, 8-bit bus connector with 

a low-line detector and battery back-up reserved for option 
modules such^s Flabh/RAM/ROM disk module and/or Flat- 
panel/CRT VGA modules 

• DMA channels: 7 


• Interrupt levels. 15 

• Keyboard connectors: A 6-pin mini-DIN keyboard connector 
is located on the mounting bracket for easy access. An 
external keyboard adapter is included. An on-board 
keyboard pin header connector is also available 

• Bus speed: 8 MHz. 

• System pertormance: 150 MHz with an 80486DX-33 MHz 
(Landmark speed V1.14). 

• Max. power requirements: +5 V @ 2.5 A 

• Operating temperature: 32 to 140"F (0 to 60»C) 

• Board size: 13.1' (L) x 4.8' (W) (334 mm x 122 mm) 

• Board weight: 1.5 lbs (0.7 Kg) 

• EMI: meets FCC class A and BZT Class A 

• MTBF: 87,100 hrs @ 25-0; 31,900 hrs @ 60"C 


Ordering Information 

□ PCA-6146-33/Bare: 

All-in-one 80486 CPU Card without CPU. Includes 256 KB 
memory, user’s manual, IDE hard disk drive cable, floppy 
disk drive cable, parallel port adapter and keyboard 
adapter. 

□ PCA-6146SX-25/0K: 

All-in-One 80486SX-25 CPU Card with 256 KB cache 
memory and all accessories of the PCA-6146-33/Bare 

□ PCA-6146SX-33/0K: 

All-in-One 80486.SX-33 CPU Card with 256 KB cache 
memory and all accessories of the PCA-6146-33/Bare 

□ PCA-6146DX-33/0K: 

All-in-One 80486DX-33 CPU Card with 256 KB cache 
memory and all accessories of the PCA-6146-33/Bare 

□ PCA-6146DX2-50/0K: 

All-in-one 80486DX2-50 CPU Card with 256 KB cache 
memory and all accessories of the PCA-6146-33/Bare 

□ PCA-6146DX2-6e/0K: 

All-in-one 80486DX2-66 CPU Card with 256 KB cache 
memory and all accessories of the PCA-6146-33/Bare 
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^ PCD 890 Dual FlasiimmOM 3lsk Card 



The PCD-890 solid-state disk emulates 
two floppy disk drives. It provides 
anywhere from 360 KB to 12 MB of 
storage using Fiash/EPROM/SRAM 
memories. When you replace 
mechanical disk drives with the PCD- 
890, your critical PC applications will 
run faster in harsh industrial 
environments with a higher degree of 
reliability. 

The size of the PCL-890's disks 
depends on the number of chips 
installed. The unit works with a wide 
assortment of supported chips from 
standard manufacturers or their 
equivalents. You can designate each as 
drive A, B, C or D. You can install up to 
two PCD-890S in your PC for at total of 
24 MB of Storage. 

The PCD-890's on-board watchdog 
timer protects your applications from 
system standstills, particularly useful in 
stand-alone or unattended 
environments requiring auto reset or 
auto reboot. 


ApplUatims 

• Diskless PCs 

• High-reliability industrial PCs 

• Stand-alone or unmanned machines 

• Sites that demand high-speed or 
heavy-duty disk operations 

• Industrial controllers 

• Network terminals 

• Industrial PCs requiring high-speed 
disk I/O 


Jsaiures 

• Emulates up to two floppy disk drives 

• Disk sizes: 360 KB to 12 MB (both 
banks linked together) 

• Drive designation: DOS drive A, B, C 
or D (1st, 2nd, 3rd and 4th FDDs) 

• Offers 24 individual 32-pin memory 
sockets divided into two banks, one 
bank for each drive 

• Accepts 128Kx8 Flash/EPROM/SRAM 
or512Kx8 Flash/EPROM/SRAM 

• Fully software-compabble with 
mechanical floppy disk drives. 
Requires no special software 
development 


• Power-on auto-boot feature; user- 
defined password and user's prompt, 
excellent for OEMs 

• Up to two PCD-890S can be installed 
in one PC 

• On-board EPROM programming 
circuitry with easy-to-use menu 
driven programming utility software 

• Lithium backup battery 

(3.6 V @ 1.8 AHr) for 5-year data 
retention (with maximum load of 24 
SRAM chips) 

• Connector for external battery 

• Each card occupies only 16 KB of 
system memory space 

• Watchdog timer with selectable time¬ 
out period (100 msec and 1.6 sec) 

• Memory-mapped data transfer 

• Switch (enable/disable) between 
floppy disk drives and PCD-890S by 
software 

• Connector with pins for +5 V, +12 V, 
GND, PFO (Power Failure Output) and 
WOO (Watchdog Output) signals 

• All solid-state construction for 
environments hostile to diskettes 
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Dual Flash/RAM/ROM Disk Card 



Introiluttion 

The PCD-890 solid-state disk emulates 
two floppy disk drives. It provides 
anywhere from 360 KB to 12 MB of 
storage using Flash/EPROM/SRAM 
memories. When you replace 
mechanical disk drives with the PCO- 
890, your critical PC applications will 
run faster in harsh industrial 
environments with a higher degree of 
reliabiiity. 

The size of the PCL-890's disks 
depends on the number of chips 
installed. The unit works with a wide 
assortment of supported chips from 
standard manufacturers or their 
equivalents. You can designate each as 
drive A, B, C or D. You can instali up to 
two PCD-890S in your PC tor at totai of 
24 MB of storage. 

The PCD-890's on-board watchdog 
timer protects your applications from 
system standstills, particularly useful In 
stand-alone or unattended 
environments requiring auto reset or 
auto reboot. 


Applitations 

• Diskless PCs 

• High-reliabillty industrial PCs 

• Stand-alone or unmanned machines 

• Sites that demand high-speed or 
heavy-duty disk operations 

• industrial controllers 

• Network terminals 

• Industrial PCs requiring high-speed 
disk I/O 


Features 

• Emulates up to two floppy disk drives 

• Disk sizes: 360 KB to 12 MB (both 
banks linked together) 

• Drive designation: DOS drive A, B, C 
or D (1st, 2nd, 3rd and 4th FODs) 

• Offers 24 individual 32-pin memory 
sockets divided into two banks, one 
bank tor each drive 

• Accepts 128Kx8 Flash/EPROM/SRAM 
or 512Kx8 Flash/EPROM/SRAM 

• Fully software-compatible with 
mechanical floppy disk drives. 
Requires no special software 
development 


• Power-on auto-boot feature; user- 
defined password and user's prompt, 
excellent for OEMs 

• Up to two PCD-890S can be installed 
in one PC 

• On-board EPROM programming 
circuitry with easy-to-use menu 
driven programming utility software 

• Lithium backup battery 

(3.6 V@ 1.8 AHr) for 5-year data 
retention (with maximum load of 24 
SRAM chips) 

• Connector for external battery 

• Each card occupies only 16 KB of 
system memory space 

• Watchdog timer with selectable time¬ 
out period (100 msec and 1.6 sec) 

• Memory-mapped data transfer 

• Switch (enable/disable) between 
floppy disk drives and PCD-890s by 
software 

• Connector with pins for +5 V, +12 V, 
GND, PFO (Power Failure Output) and 
WDO (Watchdog Output) signals 

• All solid-state construction tor 
environments hostile to diskettes 
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Solid State Storage Devices 



Q. What special features does a Flash/ 
RAM/ROM disk otter for the 
industrial environment? 

A. Flash/RAM/ROM disks are the solid- 
state equivalents ot mechanical disk- 
drives. They offer faster data access 
and longer MTBF, characteristics 
which make them the ideal solution 
for critical commercial or industrial 
applications. 

Mechanical disks are highly 
susceptible to breakdown in severe 
industrial environments. A Flash/ 
RAM/ROM disk uses Flash, SRAM 
and EPROM memory to store your 
data and application programs 
instead of the magnetic particles on a 
rotating disk. Although the Initial 
cost for the solid-state disk Is higher, 
it gives you faster and more efficient 
operation, a longer lifespan and a 
lower risk of breakdown or data loss 
during critical manufacturing or 
commercial processes. 

Q. What is a memory-card drive? 

A. A memory-card drive uses credit- 
card sized memory cartridges to 
store data using procedures 
established in the PCMCIA 1.0/JEIDA 
4.0 standard. Card drives link with 
the PC/ISA bus and allow you to 
write to and read from an 1C memory 
card as you would a magnetic disk. 
Like a floppy disk, you can remove a 
cartridge from a drive on one PC and 
use it in another PC’s card drive. 

Our memory-card drives offer a seek 
time that Is orders of magnitude 
faster than mechanical disks. Card 
drives are also much less vulnerable 
to wear, part failure or vibration. 
Industrial PCs are only one of many 
candidates for these systems. 
Memory card drives are ideal in any 
environment that requires portability, 
ruggedness and fast access. That's 
why they are popular for fleet 
vehicles, robots, remote data loggers 
and mobile computer systems. 


Q. What are the differences befween 
applications for Flash/RAM/ROM 
disk cards and applications for 
memory-card drives? 

A. Flash/RAM/ROM disks appear in 
applications which demand large 
storage capacity, easy memory 
expansion, complete DOS 
compatibility and the security which 
diskless operation provides. 

They make excellent direct 
replacements for mechanical drives 
because they completely emulate 
DOS operations, withstand more 
severe conditions and read and write 
much faster. Their watchdog timers 
make stand-alone or unmanned 
operations much easier to manage 
because they can trigger auto-resets 
or auto-reboots in case of power 
failures. Disk cards also work well in 
high-security environments because 
they’re entirely enclosed within your 
PC and therefore tar more tamper¬ 
proof than disk drives. Applications 
that generate lots of data will find 
ample storage space on a disk card. 
Any application that rewards 
portability, mobility and low power 
consumption wiii benefit from a 
memory-card drive. They’ve won 
favor with designers of test 
equipment, data-control systems and 
data ioggers because of their smail 
size, light weight and the availability 
of standard memory cards in several 
sizes from 128 KB to 64 MB. The 
cards themselves weigh little (from 
1 to 1.5 ounces [138 to 206 g]) and 
can be moved from drive to drive just 
like floppy disks. 


Q. Whaf are the different types ot 
memories used in solid-state 
disks? 

A. Three types of memory are available: 
EPROMs, battery-backed SRAM and 
Flash memory. All three types offer 
you storage capacities that equal or 
beat those ot floppy disks. At the 
same time, since they have no 
moving parts, they offer greater 
reliability than mechanical drives. 


An EPROM (Erasable Programmable 
Read-Only Memory) provides storage 
that is nearly nonvolatile, for it is 
written electrically and can only be 
erased by UV light. SRAMs with 
battery backing are normal static 
RAMS coupled with a battery that 
retains data when normal power is 
withdrawn. Flash memory operates 
like an EPROM, except that It can be 
programmed and erased while on¬ 
board. It provides the same long data 
retention but reduces the time 
required to store the data. 


Q: How does the solid state disk work? 

A: The solid state disk uses memory 
chips (Flash. SRAM or EPROM) to 
store programs and data instead of 
the magnetic particles on the 
mechanical drive’s disk. When the 
system boots, the disk card modifies 
the BIOS INT-13 disk I/O routine. The 
routine then translates read and write 
commands to the disk card so that 
they will correctly access the 
memory chips. You don’t need any 
special drivers. You simply set the 
drive to act as drive A: or C: and use 
standard DOS commands (COPY, 
DIR, etc.) to manipulate your data. 

If you use Flash or SRAM for the 
solid state disk, you can read or write 
data. If you use EPROM, files on the 
disk are read only. The PCD-890 can 
program some common EPROM 
chips on board. Otherwise you will 
need an external programmer to load 
your program and data files on the 
EPROMs. 


Q: How do I boot from a solid state 
disk? 

A: It's easy. Simply set the jumpers on 
your solid state disk to emulate drive 
A: (the 1st FDD), then copy your 
application files to the disk along 
with the standard system files 
required to boot (command.com, 
io.sys, autoexec.bat, etc). Next time 
you start your computer, it will boot 
from the solid state disk. 
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PCD-890 


Spetituations 

• Flash: ATMEL29C010 (128 Kx8), 
29C040 (512 Kx8) 

INTEL or AMD 28F010 (128 Kx8) 

• EPHOM: ATMEL 27C010 (128 Kx8), 
27C040 (512 Kx8) 

• SRAM: CXK581000P (128 Kx8). 
CXK584000P (512 Kx8) 

Note: You may use code-equivalent 
chips but make sure to use only 
memories from recognized suppliers 

• Battery: 3.6 V(1.8 AHr) lithium 
batteiy backup 

• Operating temperature: 

32 tolWE (OtoeCC) 

• Power: 45 V @ 1 A maximum lor 
normal applications, 412 V @ 300 mA 
maximum for programming EPROMs 

• Board size: 13.3‘ (L) x 4.2’ (W) 

(340 mm X107 mm) 


Ordering Information 

□ PCD-890: 

Dual Flash/RAM/ROM Disk Card with 
0 KB memory, user's manual and 
utility diskette 
a M-27C010X3: 

Three 128 KB EPROM devices 

□ M-27C040X3: 

Three 512 KB EPROM devices 

□ M-581000X3: 

Three 128 KB SRAM devices 

□ M-584000X3: 

Three 512 KB SRAM devices 
a M-29C010X3: 

Three 128 KB (45 V) Flash memories 

□ M-29C040X3: 

Three 512 KB (45 V) Flash memories 


Memory Configuration 

The following table shows the number of EPROM, Flash or SRAM chips required for 
each disk size. 





























WPCD‘892 


Flash/RAM/ROM Disk Card 



Introduftion 

The PCD-892 half-size Flash/RAM/ROM 
disk card uses up to 6 MB of SRAM, 
EPROM or Flash memory chips to 
replace a floppy disk drive. It offers 
faster access times and better pro¬ 
tection from the vibration, vapors and 
contaminants found In harsh industrial 
environments. The emulated drive is 
identified conventionally as A, B, C or 0 
and obeys standard DOS commands; no 
special software is required. 

An optional lithium battery (3.6 V, 

1.8 AHr) preserves data stored on an 
SRAM disk in case of power failure. The 
PCO-892 also comes equipped with a 
watchdog timer which outputs a TTL- 
low signal if the CPU's processing 
comes to a halt due to a software bug or 
EMI. You can use this signal to activate 
an LED or alarm or to trigger an auto¬ 
reset or auto-reboot. 

Applhations 

• Programs that require frequent, high¬ 
speed disk access 

• Diskless PCs and workstations 

• Security systems 

• Embedded control systems 

• Unmanned (run-only) controllers 

• Industrial control systems 

• Instrumentation systems 

• Testing systems 


Features 

• PC/AT compatible half-size card 

• Can be enabled or disabled in 
software 

• Fully software-compatible with 
conventional drives, requires no 
special software development 

• Auto-bootable when emulating 
drive A 

• Disk size from 360 KB to 6 MB 

• Accepts 128KX8 Flash/EPROM/SRAM 
or 512Kx8 Flash/EPROM/SRAM 

• Lithium battery (3.6 V @ 1.8 AHr) for 
SRAM data retention of no less than 
ten years 

• On-board connections for exfernal 
battery, and +12 V power sources, 
power failure warning and watchdog 
timer outputs 

• Each card occupies only 16 KB of 
system memory space 

• Selectable watchdog timer intervals of 
100 msec and 1.6 sec 

• Memory-mapped data-transfer 

• 32 to 140'F (0 to 60»C) operating 
temperature 

• Password protection against 
unauthorized changes 

• User-defined prompt offers easy 
customizing for OEMs 


SpetifUations 

• Supports the fallowing memory 
devices: 

Flash 

ATMEL 29C010+5V(128Kx8). 
ATMEL 29C040 +5 V (512 KxB) 
AMD/INTEL 28F010 +12 V (128 Kx8) 
or equivalent. Approved 
manufacturers only. 

EPROM 

ATMEL 27C010 (128 Kx8). 

27C040 (512 Kx8) or equivalent. 
Approved manufacturers only. 

cS< M1000P (128 Kx8), 
CXK584000P (512 Kx8) or equivalent. 
Approved manufacturers only. 

• Power requirements: 

+5 V @ 0.5 A max. (normal 
operations): +12 V @ 50 mA max. 
(during flash memory programming) 

• Board size: 

7.3‘x3.9‘(185 mm X 98 mm) 


Ordering Information 

□ PCD-892A: 

Flash/RAM/ROM Disk Card with 
battery 

a PCD-892B: 

Flash/ROM Disk Card without battery 

□ M-27C010X3: 

Three 128 KB EPROM devices 

□ M-27C040X3: 

Three 512 KB EPROM devices 

□ M-581000X3: 

Three 128 KB SRAM devices 
a M-584000X3: 

Three 512 KB SRAM devices 
a M-29C010X3: 

Three 128 KB (+5 V) Flash memories 
a M-29C040X3: 

Three 512 KB (+5 V) Flash memories 
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PCI-B44 


8‘port Intelligent RS-232 Card 



Introduttion 

We designed the PCL-844 Intelligent 8-port RS-232 or RS- 
422 interface card for lab and industrial applications where a 
PC needs to communicate with terminals, modems or other 
instruments. RS-422 applications use the optional PCL-8442 
8-port isolated RS-232 to RS-422 converter, shown on the 
following page. You can install up to four PCL-644 cards for a 
total of 32 ports in any AT/ISA bus 286/386/486 based PC. 

The PCL-844's on-board 12 MHz 80286 processor takes over 
the communications load from the host PC. When you are 
processing large amounts of data from multiple ports, 
servicing the interrupts alone consumes a large percentage of 
the capacity of your computer's CPU, The PCL-844 serves as 
a high-speed dedicated interrupt processor. Its CPU directly 
controls the board's CD180 RISC-based UART, guaranteeing 
38,400 bps performance over eight high-speed data ports. 

The PCL-844 is virtually a self contained computer in its own 
right. It contains 512 KB of dual-ported RAM which you can 
use to store and run programs. The dual-port RAM maps into 
the host system's address space to give you the fastest 
possible data transfers between the PCL-844 and PC-memory. 
When the PCL-844 initializes, it downloads the driver software 
(which functions like a PC's BIOS) into on-board SRAM. This 
improves performance and makes version upgrading easy, 
with no hardware redundancy. 

Each PCL-B44 comes with software drivers for DOS and 
Windows (PC-ComLIB, described on the following page). 
These drivers support most common languages, including C, 
Pascal, Visual Basic, Quick Basic, assembly and Clipper. The 
PC-ComLIB package also includes the DataScope data viewer, 
terminal emulator and self-diagnostic utilities for easy 
troubleshooting and debugging. 


Features 

• 12 MHz 80286 processor, CD180 RISC-Based UART, 

512 KB dual ported RAM. 

• Baud rate up to 38400 bps with eight ports on line 

• Complete RS-232 modem control signals 

• Maps to just 16 KB of system memory. Choose one of six 
addresses from C8000 to OCOOO. 

• Many IRQ options: 2,3,4, 5,7,10,11,12 or 15 

• Easy-to-use menu driven installation program 

• LEDs on connection box let you monitor the TxD/RxD status 
of any port 

• Links to peripherals up to 4000 ft from controller (RS-422) 

ApplUations 

• Data acquisition and control with RS-232/RS-422 based 
devices 

• PLC monitoring and control 

• Instrument controller, distributed control system 

• Modem server, database server, POS controller 

• Multi-user system 

Spetifirations 

BoaM 

• Number of ports: 8 

• Processor: 12 MHz 80286 

• Dual-ported RAM: 512 KB 

• SRAM: 16 KB 

• UART. RISC-based CD180 

• Total ports in one system: 32 

• Operating temperature: 32 to 122"F (0-50"C) 

• Power consumption: 

+5 V@ 1.5 A, +12 V @ 120 mA, -12 V @ 180 mA 

• Dimensions: 13.3 x 4.7 in. (338 x 120 mm) 

• Weight: 1.5 lb (0,67 Kg) 

RS-232 interface 

• Signals: 

TxD, RxD, RTS, CTS, DTR, DSR, DCD and GND 

• Mode: asynchronous full duplex 

• Communication rate: 50 to 38,400 bps 

• Stop bits: 1 or 2 

• Parity: even, odd or none 

• Data bits: 7 or 8 
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PCL^743/745 



RS-422/4B5 Interface Can! Block Diagram 


Pin Assignment 


RTS- 

RTS+ 




CTS+ 8 


CTS- 8 : 


TX- 

TX+ 

RX+ 

RX- 

GND 


RS-485 Programming Example 

10 ' Configuced as CCmi with the 

driver /receiver bit enabled 

20 BASE% = &3F8 

100 OPEN"COM1:9600,N,8,1,RS"AS#1 

110 00TBASE%+7,1 'Enabledriver 

120 PRINT #1, DATA1$ 'Senddata 


Wiring Diagram (2-wlre) 



Device 0 Device 1 Device n 


Ordering Information 

□ PCL-743: 

General-purpose RS-422/485 Interface Card, user’s manual 

□ PCL-745: 

Isolated RS-422/RS-485 Interface Card, user’s manual 

□ PCLS-802. 

PC-ComLIB Serial Communication Programming Library 


200 OUTBASE%-l-7,2 'Enable receiver 

210 INPUT #1, DATA2$ 'Receivedata 


ODTBASE%+7,0 


'Disable driver 
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PCL-812/812PG 


MultiLab Analog 
& Digital I/O Card 



lntrodu<tiott 

The PCL-812 and PCL-812PG are multifunction analog and 
digital I/O cards which offer the five most desired measure¬ 
ment and control functions tor PC/AT and compatible sys¬ 
tems: MD conversion, D/A conversion, digital Input, digital 
output and counter/timer. They neatly package 16 12-bit 
analog input channels, two 12-bit analog output channels, 
16 digital input channels, 16 digital output channels and a 
programmable counter/timer on a tull-size card. 


• Includes C/C++, PASCAL and BASIC drivers as well as 
calibration, demo and example programs 

• Rich application software support 

• Wide variety of external daughter boards 

PCL-812PG only 

• Programmable A/D ranges (gains) 

Applitations 

• DC voltage measurement 

• Transducer/sensor interfacing 

• Waveform analysis 

• Process control 

• Programmable voltage output 

• Contact closure monitoring 

• Digital signal and BCD interfacing 

• Industrial ON/DFF control 

• Multiplexer and relay control 

• Frequency, period and pulse width measurement 

• Event counting and pulse train generation 

I/O funttions 


In addition to all the features listed above the PCL-812PG 
offers the convenience ot programmable analog Input ranges. 
With the PCL-812PG selection of an analog input range is not 
done by DIP switches, but by software commands. For 
applications which need different gains for different channels 
or different gains for different stages of a process, the PCL- 
812PG offers convenience and maximum resolution. 

Rich software support, numerous I/O options and a wide 
range of available daughterboards make the PCL-812 and 
PCL-812PG ideal for industrial applications that require a 
combination of analog and digital I/O. 

Features 

PCL-812 and PCL-812PG 

• 16 single-ended 12-bit analog input channels 

• Two 12-bit analog output channels 

• Programmable sampling rate of up to 30 KHz 

• A/D with DMA or interrupt 

• 16 digital output channels 

• 16 digital input channels 

• Programmable timer/counter 


Analog input 

The PCL-812 and PCL-812PG use an industrial standard 
12-bit successive approximation A/D converter (AD574) with 
sample and hold for accurate, high-speed /VD conversions. 

The typical conversion time is 25 microseconds. 

You can trigger the A/D conversion in three ways: by program 
control, by on-board programmable pacer or by an external 
trigger pulse. The on-board pacer uses two 16-bit timer/ 
counter channels from an Intel 8253. A crystal oscillator 
provides a 2 MHz time base. This oscillator lets the pacer 
generate trigger pulses with frequencies ranging from 
500 KHz to 0.00046 Hz (1 pulse every 36 minutes). 

You can perform /VD data transfer in three ways: by program 
control, by interrupt service routine or by DMA. If you use 
interrupt data transfer you can jumper-select any IRQ level 
between 2 and 7. It you use DMA data transfer you can Jumper 
select either DMA channel 1 or 3. 

Analog output 

As a complement to the analog inputs, the PCL-812 and PCL- 
B12PG also provide two 12-bit double-buffered analog output 
channels. You can operate their D/A converters with an 
internal fixed reference in the 0 to 5 V output range or with an 
external reference for 0 to +10 V or 0 to -10 V output. 
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Specifications 


PCL-1800 


Blotk diagram for the PCl-1800 


Pin Assignment 



Connector 1 {A/Q, D/A) 


+12 V 
AIHO 
A1H1 
AIH2 
AtH3 
AIH4 
AIH5 
A!H6 
A1H7 
AGND 
VREF 
AGND 
DAIVREF 
AGND 
DGND 
DAECLK 
ECLK 
OUTO 
+SV 


AGND 

A1L8 

AIL9 

A!t10 

A1L11 

A1L13 

AIL14 

A1L15 

A1L15 

AGND 

DAOOUT 

OAOVREF 

DA1DUT 

AGND 

DGND 

TRIGO 

GATED 

OUT2 


Connector 2 (D/0) 


D/0 0 
D/02 
D/0 4 
0/0 6 
D/08 
D/DIO 
D/012 
D/014 
D.GNO 
+5V 


D/01 

D/0 3 

D/05 

D/07 

D/09 

D/011 

D/013 

0/015 

0/0 D.GND 

+ 12V 


Ordering information 

□ PCH800; 

330 KHz High-speed DAS Card, user's manual and utility diskette with BASIC, 
C/C++ and Pascal drivers 


Connector 3 (D/I) 


D/IO 
D/12 
D/14 
D/16 
D/18 
D/110 
D/112 
D/114 
D.GND 


1 2 
3 4 
5 6 
7 8 
9 10 
11 12 
13 14 
15 16 
17 18 
19 20 


D/115 

D/I D.GND 
■-12V 
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Specifications 


PCL-812/812PG 


Digital I/O 

The PCL-812 and PCL-812PG come with 16 digital inputs and 
16 digital outputs, accessed via two 20-pin dual-in-line 
connectors. These connectors are standard on most I/O cards 
and daughterboards in the PC-LabCard family. Digital inputs 
are normally set high (value = 1) without any input and 
change state with the input signals accordingly. Digital 
outputs are normally set low (value = 0) at initial state and 
stay at the same state (buffered) until the next output 
operation occurs. 

Timer/counler 

The third timer/counter channel on the Intel 8253, powered by 
an internal or external time base, can be used to count events 
or measure frequency, period and pulse width. 

Wait slate Insertion 

Because of the wide variety of CPU and bus speeds in the 
market we designed the PCL-812 and 812PG with a wait-state 
insertion capability. Wait-state insertion addresses most 
speed compatibility problems, allowing you to use these cards 
In PCs with speeds ranging from 16 MHz (80286) up to 66 
MHz (80486DX2). This feature ensures that your card will 
keep up with future technology. 

Spesifitations 

Analog Input 

• Channels: 16 single-ended 

• Resolution: 12 bits 

• Converter: Honeywell HADC-574ACCJ or equivalent 

• Conversion time: 25 microseconds (max. 30 KHz) 

• Input range (in V): 

PCL-812: ±10,±5,±2, ±1 

PCL-812PG: ±10, ±5, ±2.5, ±1.25, ±0.625, ±0.3125 

• Range selection: 

PCL-812 by DIP switches, PCL-812PG by software. 

• Trigger mode: by software, on-board/external trigger 

• Data transfer: by program control. Interrupt (IRQ 2 to 7) or 
DMA (Channel 1 or 3) for single channel scan 

• Accuracy: 0.01% of reading ±1 bit 

• Common mode rejection: 60 dB typical 

• Input impedance: >10 Mn 

• Ovenioltage: Continuous ±30 V,^ max. 


Analog output 

• Channels: Two double-buffered 12-bit channels 

• D/A range (in V): 

PCL-812: 0-5, 0-10 (w/external reference) 

PCL-812PG: 0-5, 0-10 (w/internal reference); ±10\/ max. 
with external AC or DC reference (accuracy for output above 
±9 V may vary depending on power supply used) 

• Settling time: 30 microseconds 

• Output current: ±10 mA max. 

• D/A device: MP7623KN or AD7541AKN or equivalent 

• Linearity: ±Vi bit 
Digital input 

• Channels: 16 

• Logic level 0: 0 to 0.8 V„ 

• Logic level 1:2.0 to 5.0 

• Input load: 

0.4 mA max. @ 0.5 V (low), 50 pA max. @ 2.7 V (high) 
Digital output 

• Channels: 16 

• Logic level 0: 0 to 0.4 

• Logic level 1 : 2.4 to 5.0 

• Driving capacity: Sink: 8.0 mA @ 0.5 V 

Source: 0.4 mA @ 2.4 V 
A/D pacer and counter (8253) 

• A/D pacer: 32-bit timer with a 2 MHz time base. 

• Max. and min. rates: 500 KHz to 0.00046 Hz (one sample 
every 36 minutes) 

• Counter; One 16-bit counter with a 2 MHz lime base 
General 

• Power consumption: 

-f 5 V @ 500 mA typical, 1.0 A max. 

+ 12 V @ 50 mA typical, 100 mA max. 

-12 V @ 14 mA typical, 20 mA max, 

• Operating temperature: 32'>F to 140”F (0 to 50”C) 

• I/O ports; 16 consecutive bytes 

• Connectors: All I/O channels are accessed through five on¬ 
board, 20-pin, dual-in-line connectors 

• Base address: 

DIP-switch seiectable, default setting is H220 
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PCL-812/812PG 


Ordering Information 

□ PCL-812: PCL-812 Multi-Lab Card, user's manual and utility diskette, with BASiC, 
C/C++ and PASCAL drivers 

a PCL-812PG: PCL-812PG, user’s manuai and utiiity diskette with BASIC, C/C++ 
and PASCAL drivers 

□ OPT 002; Wiring kit: inciudes PCLD-780 wiring terminai board, PCL-10501/PCL- 
10502 industrial wiring adapters and cabies. 

a OPT 003: Three application software packages: PCLS-700-1 PC-LabDAS, PCLS- 
800 PC-Scope and PCLS-702 LABTECH ACQUiRE 

□ PCL-812-CS: Complete package; PCL-812 + OPT 002 + OPT 003 

□ PCL-812PG-CS: Complete package; PCL-812PG + OPT 002 + OPT 003 

□ PCLS-DLL-2: Windows DLL driver for PCL-812/PG or PCL-711B 


Pin Assignment 


CametarHUD) 



Cmiiector2fM>,m) 
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PCL-830 


10-channel Timer/Counter Card 



Introduttion 

The PCL-830 Is a general purpose counterAimer and digital 
I/O card for PC/AT compatible computers. It provides ten 
16-blt up/down counter channels and frequency dividers for 
Its on-board 4 MHz crystal time base. It also includes 16 
digital outputs and 16 digital inputs. Two AMD 9513 chips 
provide a variety of powerful counterAimer function modes to 
match your industrial and laboratory applications. 

ApplUations 

• Event counting 

• Industrial automation (flowmeter and wattmeter monitoring) 

• Programmable frequency synthesis 

• Frequency counter 

• Pulse-width and period measurement 

• Time-delay generation 

• Frequency-shift keying 

• F/V conversion and pulse accumulation 

Features 

• Periodiwnterrupt generation 

• 10 Independent 16-bit up/down counters 

• Binary or BCD counting 

• Programmable frequency output 

• Complex duty-cycle output 

• Two alarm comparators (on counters #1/#2 and #6/#7) 

• Single-shot or continuous output 

• Programmable count/gate source selection 

• Programmable Input and output polarity 

• Programmable gate functions 

• 16-bit TTL input and 16-bit TTL output ports 

• Selectable Interrupt Input channel 

• Up to 6.8 MHz Input frequency 

• Time-of-day option 


SpetHUations 

Counter 

• Description: Ten independent 16-bit counters 

• tnput level: TTL-compatIble 

• Output level: TTL-compatIble, \l^= 0.4 V max @ 3.2 mA 
sink; \/^= 2.4 V min @ 0.2 mA source 

• Input frequency: 6.8 MHz max 


• Connector: Two 20-pin flat-cable connectors 

• Time base: 1.00 MHz 

• Frequency stability: ±100 PPM 
Digital VO 

• Channels: 16 TTL-compatible outputs (16 bits) 

• Driving capacity: Sink 8.0 mA @ 0.5 V (low), source 
0.4 mA@ 2.4 V (high) 

General 

• Dimensions: 7‘ x 4.2" (179 mm x 107 mm) 

• Power consumption: +5 V @ 600 mA typical 
Pin Assignment 


CN1 




Ordering Information 

□ PCL-830: 10-channel Counter/Timer Card, 
user's manual and utility diskette 
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PCl-838 


Stepping Motor Control Card 



IntroduKtion 

The PCL-838 Stepping Motor Control Card turns your PC into 
a multi-axis motion-controi station. The intelligent PCL-838 
fetches operation data from its dual-port RAM to generate 
pulses for each channel, giving higher performance. 

You can install more than one card in your PC, each card 
controlling up to three motors at the same time. The included 
DOS device driver provides powerful commands that support 
you to easily Incorporate motion control in your application 
software. 

Applitations 

• Precise X-Y-Z position control 

• Precise rotation control 

• Robotics and assembly equipment 

• Other stepping-motor applications 

Features 

• Independent and simultaneous control of up to three 
motors 

• Device driver with a language-independent high-level 
command Interpreter 

• Programmable step rate from 1 to 7000 pps (pulses per 
second) 

• Programmable initial speed, final speed and time duration 
with calculated linear acceleration and deceleration 

• Supports one clock (pulse and direction) and two clock (CW 
pulse and COW pulse) control modes 


Spedfitations 

Pulsa-train generator 

• Independent channels: 3 

• Steps per command: 1 to 65,535 

• Speed range: From 1 to 7000 pps (pulses per second) 

• Operating modes: Either two-pulse (CW, CCW) mode or 
pulse-direction mode, selectable by DIP switch 

• Signals: Opto-coupled with open collector 

• Pull-up voltdge: +5 V, +12 V, or external 

• Pull-up resistor: 4.7 KH 

• Driving capacity: 30 mA ® 0.5 V 
Digital I/O 

• Input: 24 channels, TTL compatible 

• Output: 24 channels, TTL compatible 
General 

• Dimensions: 13.3’ (L) x 3.8’ (W) (340 mm x 98 mm) 

• Power consumption: 

5 V @ 1.2 A typical, 12 V external load only 

Pin assignment 
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COMMON: Isolated common point 
EXT.VCC: External power source 
PULSE/CCW: Stepping pulses or CCW pulses 
DIH/CW: Direction signal orCW pulses 
E.STOP: Emergency stop 
6ND: Ground ot the PC 
0/1 0 to D/I 7: Digital Inputs 
D/0 0 to D/0 7: Digital outputs 
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UNIT 



MILLED RLUMINUM PLATE 


INERTIAL MERSUREMENT UNIT 

9 PIN MALE CONNECTOR 


POWER GND 
+28 VDC IN 
SIGNAL GND 

RX 


TX” 


“THE USER RECEIVES ON THIS LINE. 




WATSON INDUSTRIES, INC. 

3041 Melby Road Eau Claire, Wl 54703 

Phone (715)839-0628 • FAX (715)839-8248 
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INERTIAL MEASUREMENT 
UNIT (IMU-600AD) 


Watson Industries has provided a variety of sensor packages to 
customers world wide. We have listened to the many demands 
for a complete dynamic sensor package which Is hl^y reliable 
and easy to use. The IMU-600AD combines multi-layer surface 
mount technology with proven sensor expertise to deliver a 
complete sensor package - Trl-Axlal rate and acceleration, bank 
and elevation, and magnetic heading - all In one compact 
package. All data Is sampled 50 times a second with 16 bit 
accuracy. 


RATE GYROS - The rate gyros are solid-state, vibrating element 
angular rate gyros. They combine excellent performance with 
small size and low power. 

ACCELEROMETERS - The accelerometers are Instrumentation 
grade. Alternate ranges are available. 

BANK AND ELEVATION - These sensors are liquid capadtlve 
vials which provide excellent repeatlblllty, resolution, as well as 
a small size. The bank and elevation sensors provide the 
reference to calibrate the bias settings for the accelerometers 
as well as information for Euler coordination transformation on 
the tri-axlal magnetometer data. 

MAGNETIC HEIADING SENSOR - A trl-axlal magnetometer, 
combined with the bank and elevation sensors, provide 
accurate magnetic heading data. The data from the roll and 
pitch sensors provides Information for an euler coordinate 
transformation of magnetic data. This results in accurate 
heading information without the use of gimbals. 
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IMU-600AD SPECIFICATIONS 

RATE RANGE 

±1(X)Vsec 

RATE ACCURACY 

1% F,S. 

RATE RESOLUTION 

< 0.05VSEC 

RATE BIAS 

±5% F.S. 

ACCELERATION RANGE 

±3 g's 

ACCELERATION ACCURACY 

<0.5% F.S. 

ACCELERATION BI/VS 

<0.5% F.S. 

ACCELERATION RESOLUTION 

BETTER THAN 5 mG’s 

B/VNK AND ELEV. ACCURACY 

0.2? to30" 

SENSOR AUGNMENT 

<0.25»-ALL SENSORS 

R?EQUENCY RESPONSE 

DC-20 Hz (Accel, and Rate) 
DC-0.5 Hz (Roll, Pitch, Heading) 

HE/VDING ACCURACY 

±3*tol5»Tlt 

POWER REQUIREMENT 

+28VDC 
< 250mA 

OUTPUT FORMAT 

DIGIT/VL, RS232 

(OPTIONAL) 

ANALOG 

SIZE 

SEE DRAWING 

WEIGHT 

<2LBS 

SHOCK 

50g-$ 

TEMPERATURE 

-20^tO-t60K: 


SENSOR ALIGNMENT - AU sensors are guaranteed 
not to be misaligned with Its proper axis by no more 
than 0.3°. This feature is critical for a tri-axlal set 
of sensors. The resolution of a sensor can be 
overwhelmed by corruption of data due to sensor 
mls-allgnment 

CONVENIENCE - You Install onty one sensor 
package. 


I Industries, Ine. • 3041 Melby Road - Esu aaire, Wl 54703 TEL; (715) 839-0628 
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